Question

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

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

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

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

提前感谢您的帮助！

Answer 1

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

例如

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

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

OpenAccess非常智能，只能在这种情况下查询名/姓。现在，当屏幕最终需要person对象中的另一个属性时，您只需要更新dto和LINQ查询。

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

仅供参考，对于大型模型，查看aggregate metadata source OpenAccess提供的内容可能有助于将大型模型分解为可管理的部分。

希望这有帮助！：）

帮助构建Telerik OpenAccess域模型

1 个答案: