帮助构建 Telerik OpenAccess 域模型

发布于 2024-10-19 17:05:52 字数 706 浏览 0 评论 0 原文

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

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

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

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

预先感谢您的帮助！

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

萧瑟寒风 2024-10-26 17:05:52

一般来说，最好在单个 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 处理每个域对象。

仅供参考，对于大型模型，查看聚合元数据源”可帮助将大型模型分解为可管理的部分。

希望这有帮助！ :)

In general it is best to have a solid domain model built up in a single RLINQ file. You can then handle screen concerns by projecting queries into ScreenModels/DTOs as needed.

For Example

Say you have a person object with multiple properties, however, on a particular screen you only want to return first name & last name.

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

OpenAccess is smart enough to only query for the first/last name in this case. Now when the screen ends up requiring another property available in the person object, you only need to update the dto and LINQ query.

Also, if you plan to use the Data Service Wizard OpenAccess provides, it creates a service per OpenAccessContext. So if you have an RLINQ per entity you will have a service per entity, which would be painful to maintain on the client to say the least. If you hand roll the service layer, you would obviously have a little more control here, but you will still need to constantly remember which OpenAccessContext handles each domain object.

FYI, For a large model it may be helpful to look into the aggregate metadata source OpenAccess provides to help break up large models into manageable pieces.

Hope this helps! :)

回复收藏 0 原文

~没有更多了~