.net - 没有行为的 Entity Framework POCO-需要重新设计以消除代码异味

Question

我正在将Entity Framework Model-First与Repository和Unit of Work模式一起使用，存储库返回EF POCO。

我假设无法将行为添加到由Entity Framework生成的POCO中，所以我的代码现在充满了诸如XyzService之类的东西，它是一个单独的类，为Entity Framework生成的Xyz POCO实现业务逻辑。

我有以下问题:

这有不好的代码味道，因为我不仅拥有EF POCO，而且还为每个POCO提供服务。除了许多类之外，业务逻辑还被拆分到业务实体之外。这是贫血的反模式的例子吗？

如果我坚持使用EF，我有什么方法可以添加行为(即通过局部类)或其他方式？

看到了使用从数据层返回的业务实体(在我们的示例中是存储库)的持久性无知模式，如果我想从EF-MODEL -> REPOSITORY-DAL -> BIZ-ENTITY出发，我会看到在业务实体和EF模型POCO之间会有很多两种方式的映射。诸如Automapper之类的实用程序可以优雅地处理我可能会遇到的嵌套对象的复杂关系吗？

为了减少与其对应的EF模型实体重复的业务实体，我是否会删除EF并仅使用LINQ to SQL为每个存储库编写自己的存储库实现而更好？

任何建议的方式都可以让我专注于代码(而不是像以前那样先将目标固定在EF模型上)，然后在准备好编写持久层时最后仍然使用Entity Framework，但要避免很多事情这样做需要额外的工作和映射？ EF Code-First在这方面会更好吗？

如果我错过了任何其他有助于开发的技术(例如NHibernate)，请随时提及。

Answer 1

是的，根据Fowler所说，这是一种反模式。我个人并不认为这种反模式太令人反感，但有些人确实如此。在这里使用最佳判断。如果感觉不对且很难处理，请进行更改。

Yes。局部类可以对此提供帮助。您可以将行为放在编写的局部代码中。

Yes，如果嵌套对象具有映射设置

，则Automapper将自动处理它们

再次取决于您。如果EF使您发疯，请不要使用它。使用有效的方法以及使您感觉良好的方法。

Code first正是为此而构建的。