【问题标题】：NHibernate + Mappings + Domain Model = Over-engineering?NHibernate + 映射 + 域模型 = 过度工程？
【发布时间】：2011-01-21 02:01:24
【问题描述】：

背景

我真的很喜欢 Fluent NHibernate - 它非常棒。我不必编写那些普通的基于 CRUD 的 SQL 存储过程，这很棒（不是说有什么问题）！

在我们正在开发的应用程序上，我已经走这条路了。现在我正坐在几十个领域对象中，每个对象都有一个存储库接口和相应的具体存储库。呼！

但是等等 - 这真的为我节省了那么多时间吗？感觉好像花了更多的时间。我必须编写所有这些具有 99% 属性和 1% 业务逻辑的域对象，然后我必须定义映射。这与编写存储过程所花费的时间差不多。那么使用 Fluent NHibernate 比仅仅编写存储过程有什么好处呢？

问题

是否有任何可靠的解决方案来生成那些“属性包”域对象（在 .NET 中），这样我就不必编写它们了？我可以从中看到一些好处，只要对象提供一些可扩展性以根据需要添加额外的业务逻辑。

【问题讨论】：

标签： .net nhibernate stored-procedures orm oop

【解决方案1】：

您可以使用Auto mapping 生成映射。 NHibernate 非常适合新建应用程序，大多数使用 NHibernate 的人编写他们的域对象并从中生成数据库。你喜欢做相反的事情，你有一个现有的数据库并想要生成域对象。 NHiberante 中没有解决方案，但您可以使用 MyGeneration、CodeSmith 或一些类似的代码生成工具编写一个小脚本。

【讨论】：

【解决方案2】：

也许你应该反过来想。在开发过程中，您可以从对象生成 SQL 模式（FluentNhibernate 支持这一点）。这样你就可以在一个迭代过程中开发你的领域模型，在这个过程中可能会有很多变化。数据模型可能只是一个附录。

在我看来，编写对象就像在架构管理工具中创建表和添加字段一样简单。事实上，我相信编写业务/域对象更快:-)

如果您有一个贫乏的领域模型，可能是因为您的应用程序还很年轻。更多功能将会出现:-)

【讨论】：

【解决方案3】：

不要为每个聚合根创建单独的存储库接口和具体的存储库类，而是尝试创建单个通用存储库接口和具体实现。

如果您需要为一种特定类型的实体添加一些特定功能，那么扩展方法可以为您提供帮助。

看看 Seb Lambla 的这个例子： http://serialseb.blogspot.com/2009/08/nhibernate-repository-that-oren-wont.html

【讨论】：