目前,我们使用nhibernate将业务对象映射到数据库表。所述业务对象强制执行业务规则:如果违反了该属性的约定,则set访问器将在现场引发异常。此外,属性强制与其他对象(有时是双向的!).well,每当nhibernate从数据库加载对象(例如调用isession.get(id)时),映射属性的set访问器用于将数据放入对象中。
好的是,应用程序的中间层强制执行业务逻辑。坏的是数据库没有。有时垃圾会进入数据库。如果垃圾被加载到应用程序中,它会发出bails(抛出异常)。有时它显然应该保释,因为它不能做任何事情,但如果它可以继续工作呢?例如,收集实时报告的管理工具存在不必要失败的高风险,而不允许管理员修复(潜在)问题。
我现在没有一个例子,但是在某些情况下,让nhibernate使用“前门”属性,这也会加强关系(尤其是bidi),这会导致bug。
最好的解决方案是什么?
目前,我将在每个物业的基础上,创建一个“后门”,只为nhibernate:
public virtual int Blah {get {return _Blah;} set {}}
protected virtual int _Blah {get {return blah;} set {blah = value;}}
private int blah;
我在C 2中展示了上面的内容(没有默认属性),以演示这是如何让我们基本上得到3层,或者视图,变成废话的!!!!虽然这确实可行,但似乎并不理想,因为它要求BL为应用程序提供一个(公共)接口,为数据访问层提供另一个(受保护)接口。
还有一个额外的问题:据我所知,nhibernate没有提供一种方法来区分bl中属性的名称和实体模型中属性的名称(即,查询时使用的名称,例如,通过hql——每当向nhibernate提供属性的名称(字符串)时)。当一开始某个属性的br没有问题时,这就成了一个问题,所以在O/R映射中引用它…但是稍后,您必须添加一些确实成为问题的BR,因此您必须更改O/R映射以使用新的blah属性,它使用“blah”(字符串编程的常见问题)中断所有现有查询。
有人解决了这些问题吗?!