现在的情况是,系统要重构, 是一个老系统。
系统的架构是传统贫血模式的, SSH, Action, Service, Dao Model 你懂得。
里面很多问题,都在领域模型的一些描述中存在, 比如 代码无法重用, 逻辑混乱, 无法分辨业务等
我想采用领域模型,但是目前理论层次和思想暂时升华不上去
目前的思路, 算是先迈开一脚, 随着思路渐渐清晰以后再深入使用
系统方案是
抽象出一层application, 负责发起和结束各种业务动作。
抽象出一层 领域模型 包含细粒度的业务方法
application层调用领域模型, 如需多个动作集合,使用service
在DAO中保存和查询模型状态(数据的增删改查)。。
大体是这个思路
因为网上目前案例几乎等于没有,大部分小例子也都是基于模型的抽象来说的, 很少有完整的事例, jdon个人感觉思想层面东西太多,多过于实践。。。 而完整的应用事例也都是基于分层,换汤不换药, 就我目前的认知看来, 领域模型,似乎是传统的业务单元(model类)加上业务方法。。 时而在service调用, 时而被调。
里面的领域模型实例化的问题 到底是采用IOC 还是直接new 暂时还没考虑清楚。。
repository与DAO到底区别在哪里 尚待分析
探索啊
系统的架构是传统贫血模式的, SSH, Action, Service, Dao Model 你懂得。
里面很多问题,都在领域模型的一些描述中存在, 比如 代码无法重用, 逻辑混乱, 无法分辨业务等
我想采用领域模型,但是目前理论层次和思想暂时升华不上去
目前的思路, 算是先迈开一脚, 随着思路渐渐清晰以后再深入使用
系统方案是
抽象出一层application, 负责发起和结束各种业务动作。
抽象出一层 领域模型 包含细粒度的业务方法
application层调用领域模型, 如需多个动作集合,使用service
在DAO中保存和查询模型状态(数据的增删改查)。。
大体是这个思路
因为网上目前案例几乎等于没有,大部分小例子也都是基于模型的抽象来说的, 很少有完整的事例, jdon个人感觉思想层面东西太多,多过于实践。。。 而完整的应用事例也都是基于分层,换汤不换药, 就我目前的认知看来, 领域模型,似乎是传统的业务单元(model类)加上业务方法。。 时而在service调用, 时而被调。
里面的领域模型实例化的问题 到底是采用IOC 还是直接new 暂时还没考虑清楚。。
repository与DAO到底区别在哪里 尚待分析
探索啊