0

我的公司即将开始一个使用 Telerik 的 OpenAccess ORM 的新项目。这对我们来说是一个新产品，我们将第一次在项目中使用 ORM 而不是基于数据集的方法。我们目前对构建数据层的最佳方式存在一些分歧。具体来说，我们是否应该有一个项目的 .rlinq 文件和域模型，或者我们是否应该拥有每个屏幕/模块的 .rlinq 文件，其中只包含特定屏幕/模块所需的表格和表格中的列。为了说明后者：

假设我们有一个 Person 表，其中包含名字、姓氏、ssn、出生日期、性别和婚姻状况的字段。在个人信息屏幕中，我们需要所有这些字段，因此我们将整个表包含在该 .rlinq 文件中的域模型中。在另一个屏幕上（使用单独的 .rlinq 文件），我们只需要此人的姓氏和 ssn，因此该 .rlinq 文件中的 Person 对象仅包含姓氏和 ssn。

这种方法的主要论点是我们应该只选择特定屏幕所需的数据，而不是更多。在我们当前基于数据集的应用程序中，这是有道理的。也有人担心拥有不必要的表和关系会导致加载不需要的数据，即使它没有被请求并导致网络负载。反对这一点的论点是，我们正在分割域模型并引入不必要的复杂性，而 ORM 的部分工作是通过缓存和延迟加载来管理数据获取。我们无法就此达成协议，也无法以某种方式找到任何确凿的信息，因此我们向 StackOverflow 社区寻求帮助！

如果重要的话，我们正在构建一个基于 Windows 窗体的 Intranet 应用程序，数据层将位于 WCF 服务之后，并且数据库将有大约 100 个表。

预先感谢您的帮助！

4

1 回答 1

1

通常，最好在单个 RLINQ 文件中构建实体域模型。然后，您可以根据需要通过将查询投射到 ScreenModels/DTO 来处理屏幕问题。

例如

假设您有一个具有多个属性的人员对象，但是，在特定屏幕上您只想返回名字和姓氏。

   var myUserDto = context.People
                          .First()
                          .Select( p => new UserDto { FirstName= p.FirstName, 
                                                      LastName=p.LastName });

OpenAccess 足够聪明，在这种情况下只查询名字/姓氏。现在，当屏幕最终需要 person 对象中可用的另一个属性时，您只需更新 dto 和 LINQ 查询。

此外，如果您计划使用 OpenAccess 提供的数据服务向导，它会为每个 OpenAccessContext 创建一个服务。因此，如果每个实体都有一个 RLINQ，那么每个实体都会有一个服务，至少可以说在客户端上维护是很痛苦的。如果你手动滚动服务层，你显然会在这里有更多的控制权，但你仍然需要不断记住哪个 OpenAccessContext 处理每个域对象。

仅供参考，对于大型模型，查看 OpenAccess 提供的聚合元数据源可能会有所帮助，以帮助将大型模型分解为可管理的部分。

希望这可以帮助！:)

于 2011-06-23T18:36:40.810 回答