没有行为的实体框架POCO - 重新设计需要删除代码气味

Question

我正在使用实体框架Model-First Repository和Unit of Work模式,存储库返回EF POCO.

我假设我无法向由Entity Framework生成的POCO添加行为,因此我的代码现在已经充满了类似于XyzService实现生成的Entity Framework的业务逻辑的单独类Xyz POCO.

我有以下问题:

1. 这有一个糟糕的代码味道,因为我不仅有EF POCO,我为每个POCO提供服务.除了许多类之外,业务逻辑还在业务实体之外分割.这是贫血反模式的一个例子吗？

2. 如果我坚持EF,有什么方法可以添加行为(即通过部分类)或其他方式？

3. 看到使用来自数据层的返回业务实体的持久无知模式(在我们的例子中是一个存储库),如果我想从中EF-MODEL -> REPOSITORY-DAL -> BIZ-ENTITY看到,那么在业务实体和EF模型POCO之间会有很多双向映射.Automapper等实用程序可以优雅地处理我可能面临的嵌套对象的复杂关系吗？

4. 为了减少与对应的EF模型实体重复的业务实体,我是不是更好地删除EF并且只为每个存储库使用LINQ to SQL编写我自己的存储库实现？

5. 任何推荐的方式,让我专注于代码(而不是像我一样首先固定在EF模型上),然后当我准备编写持久层时,仍然使用实体框架,但避免了很多这样做的额外工作和映射？EF Code-First在这方面会更好吗？

如果我错过了其他任何可以帮助开发的技术(例如NHibernate),那么请随意提及.

Answer 1

1. 是的，根据福勒的说法，这是一种反模式。我个人并不觉得这种反模式太令人反感，但有些人却这么认为。在这里使用最佳判断。如果感觉不对并且处理起来很痛苦，那就改变它。
2. 是的。部分类可以帮助解决这个问题。您可以将行为放入您编写的部分中。
3. 是的，如果嵌套对象有映射设置，Automapper 将自动处理它们
4. 再说一次，这取决于你。如果 EF 让您抓狂，请不要使用它。使用有效且让您在使用时感觉良好的方法。
5. Code First正是为此而构建的。