.net - EF 对象是否是业务对象？

Question

Possible Duplicate:
Using Entity Framework entities as business objects?

我正在考虑使用 Entity Framework 作为 ORM，但在进行大量阅读后，我真的很困惑 EF 对象到底适合哪里。

我的印象是 ORM 的全部意义在于消除将对象映射到关系数据库的苦差事和复杂性。您加载数据库并获得一堆像魔法一样的对象。 CRUD 的事情都是针对对象完成的。如果数据库发生变化，您会更改映射，但您的对象保持不变。

这意味着您将在整个系统中使用这些对象，并且它们将具有行为。它们是业务对象。这对我来说很有意义，而且确实是 MS tells you how to add behaviour

但是，我读过很多人说您永远不应该使用 EF 对象作为您的业务对象，因为它们只关心数据的持久性，并且会将您的业务对象与 EF 结合起来。他们建议使用 EF 作为数据层的抽象，并将它们映射到真实的业务对象。

这对我来说似乎毫无意义。当我最终仍然映射到我的业务对象时，为什么还需要另一个抽象层？如果我必须映射 EF 属性，我不妨映射 DB 列!

我认为 ORM 的全部意义在于自动化映射并充当后备存储的抽象？我错过了什么吗？

编辑:我所说的行为是指业务逻辑。验证、计算属性、业务方法等。

Answer 1

一般来说，那些说不应使用 EF 生成的类作为业务层的人是正确的。

不过，在小型应用程序中，您绝对可以直接从 UI 中使用 EF 类。

随着应用程序大小和功能的增长，您肯定会在 UI 中使用 EF 类时遇到问题:选择 N+1( View 中发生延迟加载)、序列化(循环引用)、AJAX/jQuery(发送对于微小的更新场景来说，网络上的对象图太大)等。

人们经常推荐 AutoMapper (https://github.com/AutoMapper/AutoMapper) 在 EF 类和 DTO 类以及业务层类之间进行映射，以减少编写大量映射代码的繁琐。

我认为这绝对是你可以根据你的项目需求做出的决定，并不一定有正确的答案。如果您开始感到疼痛，您可以随时改变方向。一如既往，选择最适合您的项目的最简单的解决方案。