POCO实体Fluent API与数据注释

我在域项目中编码我们的POCO实体，其中我没有提及EntityFramework或DataAnnotations。第二个项目DataAccess包含实体的数据上下文和流畅配置。POCO实体Fluent API与数据注释

某些实体属性是IsRequired或HasMaxLength。使用该域的开发人员将不知道需要什么，或者没有Xml注释文档的情况下该属性的最大长度。所以，我已经向属性添加了文档来传达需求。

但问题是，如果需求更改，我必须更新评论。这意味着我正在更新2个库 - Domain和DataAccess。

我一直担心在引用域中的DataAnnotations;我的属性没有属性。这些属性将使开发人员可以访问域实体，了解所需的内容或是否有最大长度的属性。

是否有另一种方法来传达属性的需求，而不使用实体上的DataAnnotations或必须更新实体上的Xml注释？

或者，我是否不必要地过分强调将DataAnnotation引用添加到Domain项目？

2013-05-13 IAbstract

这篇文章可能有一个很好的建议http://blog.ploeh.dk/2012/02/09/IsLayeringWorththeMapping/ – Fendy 2013-05-13 14:22:10

我个人的感觉是，它不应该是一个问题，附加这些类型的注释你的实体类。像列和表映射这样的东西最好留给数据访问层，这样您的实体就不会与模型的内在部分无关，但在我看来，指定了您的实体的*内容*的要求的注释是完全合适的。 – 2013-05-13 14:29:00

我倾向于对这些问题进行实践。如果某个属性是使用您的域的开发人员必须知道的属性，那么它属于该域。不要害怕引用数据注释。我个人无法想象引用DataAnnotations程序集的方案会妨碍可重用性。这是一个比手动更新评论更好的解决方案。 – gabnaim 2013-05-13 15:00:54

我认为这可能是一个好主意，让您的POCO实体没有注释，并且不包括对EntityFramework.dll的引用。更容易创建可移植的DLL并重用您的模型。也就是说，如果你曾经需要它。

但正如你所说，它使得它更难以拥有“自动记录”模型。你可以试着用DbContext生成模型图，这里有一个power tool。也许这足以满足您的文档需求。我在具有> 200个实体的模型上尝试过它，它工作正常。对于图表生成需要cca 2min，但之后它工作正常，对于“文档”目的很有用。

2013-05-13 14:34:14 jure

安装了电动工具，它看起来像它给我所需的文件。域实体的可移植性至关重要。谢谢！ – IAbstract 2013-05-13 15:03:43

EF电源工具创建了一个很好的Xml文档，但是我找不到任何东西来从Xml创建帮助文件或标准文档。有任何想法吗？由于Sandcastle似乎需要一个项目或二进制文件，似乎并没有提供一个好的解决方案。 – IAbstract 2013-06-14 16:42:14

回答