关于目前项目的架构思路
看了idior先生的文章《Enterprise Persistence Design》,引发了我的一点思考。
架构思路
手头的项目数据量比较大,业务逻辑似乎不复杂,基本决定采用NHibernate(不知道db4o怎么样),大致结构如下:
UI
DO(Domain Model),Service
NHibernate
Sql Server
DO直接暴露给UI,因为这样符合DRY原则,减少重复性的数据拷贝工作。复杂的涉及多个对象的逻辑可能用到Service。
分层的多少依赖于复杂度,考虑到复杂度不高,Service就不单独分层,DO也是在提供简单服务。暂时没有想清楚DAO的作用,所以也不考虑。
总结一下,也就是DO本身采用富对象方式。
开发的原则和思路:
符合KISS,DRY原则
测试驱动设计,设计支持测试。
设计哲学
我发现道家很有指导作用,为道日损,损之又损,以至于无。翻译过来就是简化再简化,简化到没有了,需求报告放进机器,按一个按钮生成软件,我们也就失业了,哈哈!
欢迎批评指正和探讨。
架构思路
手头的项目数据量比较大,业务逻辑似乎不复杂,基本决定采用NHibernate(不知道db4o怎么样),大致结构如下:
UI
DO(Domain Model),Service
NHibernate
Sql Server
DO直接暴露给UI,因为这样符合DRY原则,减少重复性的数据拷贝工作。复杂的涉及多个对象的逻辑可能用到Service。
分层的多少依赖于复杂度,考虑到复杂度不高,Service就不单独分层,DO也是在提供简单服务。暂时没有想清楚DAO的作用,所以也不考虑。
总结一下,也就是DO本身采用富对象方式。
开发的原则和思路:
符合KISS,DRY原则
测试驱动设计,设计支持测试。
设计哲学
我发现道家很有指导作用,为道日损,损之又损,以至于无。翻译过来就是简化再简化,简化到没有了,需求报告放进机器,按一个按钮生成软件,我们也就失业了,哈哈!
欢迎批评指正和探讨。