我正在为我的论坛实现数据层，我用的是NHibernate——当然，这也许不是很关键，不管是用ADO.NET朴素地实现还是用O/R Mpping问题并不大。

但是在我真正去写的时候我却觉得有点力不从心了，因为业务逻辑层的需求实在是千变万化，远远不止是简单地CRUD、列表、分页什么的，就算是能全部拆散到CRUD，却只能是说把原本一次链接查询的操作变成独立的查询，性能大大下降！我就觉得这样要做的好就比较难了，因为有时候论坛里的业务逻辑会相当复杂。

而如果我为每个业务逻辑“量身打造”一个数据层的话，就违反开放-封闭原则了，因为出现新的业务逻辑的时候就完全依赖数据层的实现了，这样我就必须再给这个新的业务逻辑“量身打造”一个数据访问的方法。

后来我就想了个比较猥琐的方法了，就是我给业务逻辑层暴露一些比较原始的接口，比如我用NHibernate实现数据层，然后在尽量封装基本数据操作的同时，给业务逻辑层暴露一个稍经封装的HQL接口，因为HQL是面向对象的，所以这时候实际上业务处还是在访问逻辑上的数据实体而不是Database（实际上，表名和列名根本不会出现在HQL里，取而代之的是类和属性，避免了直接暴露数据库给业务逻辑层）。这样业务逻辑层就能用基本数据操作（比如上面提到的CRUD，列表等）就用基本的封装，实在是逻辑太复杂，或者需要做一定性能优化的时候，用HQL来访问数据。

我不知道这样做是否合理，请大家指教。