LINQ 实体作为业务对象 - 优点/缺点
Visual Studio (sqlmetal) 生成的 dbml 文件附带映射到数据库表的实体。 您认为这些类适合用作领域模型类吗？ 或者我们应该避免它们并将它们仅隔离到数据访问层中？
谢谢
the dbml file generated by Visual Studio (sqlmetal) comes with entities mapped to database tables. In your opinion, these clases are suitable to be used as domain model classes? Or should we avoid them and isolate them into the data access layer only?
Thanks
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
在大多数情况下，实体对象和编写 SQL 之间的甜蜜层就是您的 DAL。 LINQ 的全部目的是允许使用 DAL 进行比过去更具表现力的构造。
如果没有 LINQ，在 BL 中，您可能只能对 DAL 进行诸如
GetCustomersByLastName(string)之类的方法调用。 您编写该方法的唯一原因是因为您的 BL 中的某个位置需要按姓氏获取客户。 这意味着您的 DAL 合约明确由 BL 的需求驱动。 而使用 LINQ，您可以摆脱 BL 需求和 DAL 契约之间的具体依赖关系。 DAL 可以完全不知道具体用途； 它只是公开实体的合约及其关系，BL 可以随意使用它们，而不关心它们的数据实现。 这是真正的关注点分离。如果将 LINQ 的强大功能隐藏在传统 DAL 后面，那么使用 LINQ 的意义何在？
In most cases, the layer of sugary goodness between the entity objects and writing the SQL is your DAL. The entire purpose of LINQ is to allow much more expressive constructs with your DAL than has been possible in the past.
Without LINQ, in your BL you might be limited to method calls such as
GetCustomersByLastName(string)against your DAL. The only reason you write that method is because somewhere in your BL, you need to get customers by last name. This means your DAL contracts are explicitly driven by the needs of the BL. Whereas with LINQ, you are freed from the concrete dependency between the needs of the BL and the contracts of the DAL. The DAL can be completely agnostic as to specific usage; it merely exposes the contracts of the entities and their relationships, and the BL uses them at-will without concern for their data implementation. That is true separation of concerns.If you hide the power of LINQ behind a traditional DAL, what's the point of using LINQ at all?
对于足够简单的应用程序，直接使用 LINQ 实体的一大优点是简单。 您可以避免在代码中使用另一个层，您可以避免编写大量样板逻辑来从业务对象映射到 LINQ 实体（尽管有诸如 AutoMapper 在这里可以提供很多帮助）。
另一方面，正如您所说 - 您的数据库可能不是您的域模型的真实写照。 话又说回来，如果您需要这种功能来在给定的物理数据库模型和逻辑域模型之间进行映射，也许您应该看看实体框架？ 这正是 EF 的支柱 - 这两个模型以及它们之间的映射层。
马克
For a simple enough application, the big plus of using the LINQ entities directly is - simplicity. You can avoid having Yet Another Layer in your code, you can avoid having to write a lot of boilerplate logic to map from your business object to your LINQ entities (although there are tools like AutoMapper which can help a lot here).
On the other hand, as you say - your database probably isn't a spitting image of your domain model. Then again, if you need this capability to map between a given physical database model and your logical domain model, maybe you should have a look at the Entity Framework instead? That's exactly the mainstay of EF - these two models and the mapping layer between them.
Marc
这取决于
如果您的域对象非常简单并且您的项目很小，那么使用这些类不是问题。 编写一个仅重复这些类的整个额外层将是浪费时间。
如果对象复杂并且不能以简单的方式映射，则必须使用另一层来将这些细节与数据访问层分离。
如果您确实不确定，可以直接开始使用它们，然后在明显需要时添加另一层。
It Depends
If you're domain objects are very simple and your project small, then using those classes isn't a problem. It would be a waste of time to write an entire extra layer that just repeats those classes.
If the objects are complicated and don't map in a straitforward way, another layer is essential to separating those details from the data access layer.
If you really aren't sure, you can start off using them directly and then add in another layer once it is apparent that you will need it.
我认为这取决于场景。
我现在正在编写一个 WCF 服务，我的数据模型不是很复杂，但所有表都有外键，表之间的关系使 linq 创建一个相当复杂的对象树。
从客户端的角度来看，检索所有这些对象树是没有意义的，而且返回的 xml 消息将非常重（因此，如果我不更改消息大小最大允许值，我会收到错误）。
在这种情况下，我必须在 LINQ 对象上创建自定义视图，以仅返回客户端期望检索的数据。 这是相当痛苦的，因为我不得不重写大部分实体，但最终我完全控制了与客户的通信。
I think it depends on scenarios.
I am now writing a WCF service, my data model is not very complicated but all tables have foreign keys and relationships between tables make linq create a quite complex objects tree.
From the client point of view it doesnt make sense to retrieve all this objects tree, and also the return xml message would be quite heavy (so if I dont change the message size max allowed value I get errors).
In this case I had to create custom views on LINQ objects to return just data client is expecting to retrieve. This is quite a pain as I had to re-write most of entities but in the end I have full control of the communication with client.