我和我的一个朋友讨论过使用Entity框架。我有一个项目，我用实体框架作为我的数据层制作了3层解决方案，并使用数据传输对象从业务层转移到用户界面。我真的很喜欢它给出的松耦合，因为我可以改变实体框架，例如后来休眠了。另一方面，我的朋友认为实体框架的目的是对其进行建模，以便可以在用户界面上使用它。 您如何将实体框架与您的解决方案结合起来？
答案 0 :(得分：2)
我认为我的朋友提出可互换层是Hibernate和EF的想法，但我认为它有点激烈，因为这两个框架已经包含DL-＆gt; BL功能。我认为使用像EF和Hibernate这样的框架的原因是这些，按优先顺序排列：
1.在业务逻辑中直接使用实体
2.数据库类型独立性
3.自动缓存
4. SQL抽象
期望像这样的框架也应该松散地耦合到层，只需要太多的查询解析，对象包装和解包以及各种噪声来弥补可能永远不会成为现实的可互换性。在我看来，他的提议将导致相当于：
DL - ＆gt; DL - ＆gt; BL - ＆gt; UL
有人同意吗？