Question

目前，我们使用NHibernate将业务对象映射到数据库表。所述业务对象强制执行业务规则：如果违反该属性的合同，则set访问器将在现场抛出异常。此外，属性强制与其他对象建立关系（有时是双向的！）。好吧，只要NHibernate从数据库加载一个对象（例如，当调用ISession.Get（id）时），就会使用映射属性的set访问器将数据放入对象中。

有用的是应用程序的中间层强制执行业务逻辑。有什么不好的是数据库没有。有时废话会进入数据库。如果将crap加载到应用程序中，则会失败（抛出异常）。有时它显然应该保释，因为它无法做任何事情，但如果它可以继续工作呢？例如，收集实时报告的管理工具存在不必要地失败的高风险，而不是允许管理员甚至修复（潜在）问题。

我现在没有关于我的例子，但在某些情况下，让NHibernate使用“前门”属性来强制执行关系（尤其是bidi）会导致错误。

最佳解决方案是什么？

目前，我将基于每个属性为NHibernate创建一个“后门”：

public virtual int Blah {get {return _Blah;} set {/*enforces BR's*/}}
protected virtual int _Blah {get {return blah;} set {blah = value;}}
private int blah;

我在C＃2中展示了上述内容（没有默认属性）来演示如何让我们基本上获得3层或者视图！虽然这确实有效，但它似乎并不理想，因为它需要BL为app-at-large提供一个（公共）接口，为数据访问层提供另一个（受保护的）接口。

还有一个问题：据我所知，NHibernate没有给你一种方法来区分BL中属性的名称和实体模型中属性的名称（即查询时使用的名称），例如通过HQL - 每当你给NHibernate一个属性的名称（字符串）时。当一开始，某些属性Blah的BR没有问题时，这就成了一个问题，所以你在你的O / R映射中引用它......但是之后，你必须添加一些确实成为问题的BR，所以那么你必须改变你的O / R映射以使用一个新的_Blah属性，它使用“Blah”打破所有现有的查询（对字符串编程的常见问题）。

有没有人解决过这些问题？！

Answer 1

虽然我发现你的大多数架构都有问题，但处理这些问题的常用方法是让NHibernate使用支持字段而不是setter。

在上面的示例中，您无需定义其他受保护的属性。只需在映射中使用它：

<property name="Blah" access="nosetter.lowercase"/>

这在文档http://nhibernate.info/doc/nh/en/index.html#mapping-declaration-property（表5.1。访问策略）

中有所描述

我应该用NHibernate映射哪些类？

1 个答案: