我也很少见到真正的补充血的模式。我曾经的一个团队,为某个模块添加功能时,原来的代码就是缺少血的模型,代码又长又难看懂,bug多,还很难定位。在赤裸裸的领域,补充血的领域模型,不依赖存储技术与UI展现的领域模型,可以方便的进行
这就需要你这样的有影响力的人为好的东西摇旗呐喊啊:)
然后我们决定在添加功能时顺便重构到充血模型。甚至用到Test-Driven-refactoring的技巧。这个成功的案例给我的印象非常深。充血模型后,代码可读性大大增强,代码行数大大减少,我想留给后面的人维护,也会变得更加容易。而且有了单元测试,bug少,即使出现bug,定位也容易。好处太多了。
我看我有空还是放个例子出来,请大家批评指正。
另外我想说明一点我的观点:充血模型不意味着就是OO,充血只是说把业务逻辑放到了Domain自己身上,然而仍旧可能写出过程式的代码。我感觉很多人,甚至Senior的人,都在用OO的语言(C#)写着非OO的代码,这是另一个话题了。
举个例子,比如ProductDAO,一般如果只实现了一个接口,比如IProductDAO的话,往往这个时候BLL层对DAL层的依赖较大。但是如果你的 ProductDAO ,实现了IProductDAO,IOrderProductDAO 的话,我觉得基本上可以降低很大的一部分依赖。
实际上DI和IOC还是有区别的,DI的其实更能解决问题一些,我个人觉得,因为实际上IDAL并不是由DAL层来定义自己的接口,而是BLL层来定义的IDAL,领域层需要哪些数据访问的接口。但是我们一般做的时候,...
引用 思考-总结:其实业务层依赖到DAL层,不知道大家的一个 DAL 层的对象,实现了几个IDAL的接口?
举个例子,比如ProductDAO,一般如果只实现了一个接口,比如IProductDAO的话,往往这个时候BLL层对DAL层的依赖较大。但是如果你的 ProductDAO ,实现了IProductDAO,IOrderProductDAO 的话,我觉得基本上可以降低很大的一部分依赖。
实际上DI和IOC还是有区别的,DI的其实更能解决问题一些,我个人觉得,因为实际上IDAL并不是由DAL层来定义自己的接口,而是BLL层来定义的IDAL,领域层需要哪些数据访问的接口。但是我们一般做的时候,...
"因为实际上IDAL并不是由DAL层来定义自己的接口,而是BLL层来定义的IDAL" 说的好!
以前三层IDAL往BLL里注入是手写DALFactory进行运行时的动态构建,现在一般都是在用一些IoC的工具如:Unity、StructureMap、ninject等,但一般在Asp.net中都需要在应用程序开始的时候也就是global中进行注册,一直很令我感到困惑的是:如果不用XML后台配置的方式而用纯代码的方式用IoC框架进行IDAL的注册,必定要在Web层引用DAL的dll,这样岂不是直接把数据访问层直接暴漏给前端,破坏了分层?即使用DDD中的仓储模式,也需要引用Repository的dll。
在大型erp面前,这种都是浮云。
大型erp都有自已的编译器编程语言,业务设计系统,业务界面自定义系统。
中型erp用上面的成熟模块,加部分定制。
这种只能用于小型erp系统,对于小型erp用数据表影射类在多层结构中传输,比较现实。用这个模型,搞个跨n个表的复杂查询,让人跳楼。
关系极其复杂,且不能穷尽其复杂性,是领域的特点。
实际上,如果把三层理解,三层dal处于三个不同的电脑上。界面层,只要知道逻辑层工厂和接口,就行了,所以对ioc也要做一层隔离,即不依赖于ioc具体容器.至于工厂怎么创建,那是工厂的事,有可能是远程ioc,有可能是web服务,有可能是本地,方法很多。
所以用工厂接口,隔离ioc,不依赖于具体ioc实现是必需的。
BLL内定义了IDAL,感觉像是纯粹为了DI而DI。我也喜欢UT,TDD,但是只能在一定程度上提高代码质量,有有很多场景不是UT能覆盖,对上面的测试金字塔保留意见。
可以用一个独立的project,比如叫bootstrapper,在这里做注册容器的事情。这个bootstrapper就成了唯一引用DAL的地方。
好的架构其实是一种好的约束即使偶不是从事ERP之类的企业系统应用,但读LZ此文(上下两篇),只觉逻辑清晰、深入浅出,所谓大道相通,实在是美文啊!IDAL为何不单独放一个程序集呢?放在BLL中,让DAL引用BLL的程序集,但还是有一种DAL依赖于BLL中泾渭分明的某一部分(IDAL)的感觉。
领域驱动设计还真了解不多,举个例子来说,比如图书馆程序中,Book类有一个方法是Lend()而不是BookManager?