|
|
这些都说明EvanDDD这把火已经烧到NET领域，另外一本关于。NETDDD书籍也已经出版。当然DDDJava领域生根开花多年，EvanDDD书籍就是以Java为例子的笔者板桥里人也率先在2005年推出DDD框架JdonFramework1.3版本，这些都说明，Java整个软件业先进思想的实践上总是领先一步
甚至导致开发后的Java系统性能缓慢甚至经常当机。很多人觉得这是Java复杂导致，其实根本原因在于：原先掌握的关于软件知识(OO方面)不是太贫乏就是不恰当，存在认识上和方法上的误区。越来越多人开始使用Java,但是大多数人没有做好足够的思想准备(没有接受OO思想体系相关培训)以致不能很好驾驭Java项目。
软件的生命性
反复强调都不过分。软件是有生命的这可能是老调重弹了但是因为它事关分层架构的原由。
其次才是完整的功能。一个有生命的软件首先必需有一个灵活可扩展的基础架构。
觉得一个软件功能越完整越好，目前很多人对软件的思想还是焦点落在后者：完整的功能。其实关键还是架构的灵活性，就是前者，基础架构好，功能添加只是时间和工作量问题，但是如果架构不好，功能再完整，也不可能包括未来所有功能，软件是有生命的未来生长时，更多功能需要加入，但是因为基础架构不灵活不能方便加入，死路一条。
对功能追求高于基础架构，正因为普通人对软件存在短视误区。很多吃了亏的老顺序员就此离开软件行业，带走珍贵的失败经验，新的盲目的年轻顺序员还是使用老的思维往前冲。其实很多国外免费开源框架如ofbizcompier和slide也存在这方面陷阱，貌似非常符合胃口，其实类似国内那些几百元的盗版软件，扩展性以及继续发展性严重缺乏。
关键还是取决于你如何使用这些框架来搭建你业务系统。那么选择现在一些流行的框架如HibernSpring/Jdonframework否就表示基础架构打好了呢？其实还不尽然。
存储过程和复杂SQL语句的陷阱
使用存储过程架构的人以为可以解决性能问题，首先谈谈存储过程使用的误区。其实它正是导致性能问题的罪魁祸首之一，打个比喻：如果一个人频临死亡，打一针可以让其延长半年，但是打了这针，其他所有医疗方案就全部失效，请问你会使用这种短视方案吗？
那么运行负载都集中在数据库端，为什么这样说呢？如果存储过程都封装了业务过程。要中间J2EE应用服务器干什么？要中间服务器的分布式计算和集群能力做什么？只能回到过去集中式数据库主机时代。现在软件都是面向互联网的不象过去那样局限在一个小局域网，多用户并发访问量都是无法确定和衡量，依靠一台数据库主机显然是不能够接受这样恶劣的用户访问环境的当然搞数据库集群也只是五十步和百步的区别)
现在三层架构：表示层、业务层和持久层，从分层角度来看。三个层次应该分割明显，职责分明：耐久层职责耐久化保管业务模型对象，业务层对持久层的调用只是协助我激活曾经委托其保管的对象，所以，不能因为耐久层是保管者，就以其为核心围绕其编程，除了要求其归还模型对象外，还要求其做其做复杂的业务组合。打个比喻：火车站将水果和盘子两个对象委托保管处保管，过了两天来取时，还要求保管处将水果去皮切成块，放在盘子里，做成水果盘给你合理吗？
还有一个正好相反现象，上面是谈过分依赖耐久层的一个现象。耐久层散发出来，开始挤占业务层，腐蚀业务层，整个业务层到处看见的数据表的影子(包括数据表的字段)而不是业务对象。这样顺序员应该多看看OO经典PoEA A .PoEA A 认为除了耐久层，不应该在其他地方看到数据表或表字段名。
使用数据库优点也是允许的依照EvanDDD理论，当然适量使用存储过程。可以将SQL语句和存储过程作为规则Specif一部分。
Hibern等ORM问题
但是发现Hibern性能缓慢，现在使用Hibern人也不少。所以寻求解决方案，其实并不是Hibern性能缓慢，而是使用方式发生错误：
项目中我用到struts1.2+hibernate3,最近自己正搞一个项目。由于关系复杂表和表之间的关系很多，很多地方把lazi都设置false,所以导致数据一加载很慢，而且查询一条数据更是非常的慢。
因此，关键是需要设计出高质量的对象模型，遵循DDD领域建模原则，减少降低关联，通过分层等有效方法处置关联。如果采取围绕数据表进行设计编程，加上表之间关系复杂(没有科学方法处置、侦察或减少这些关系)肯定导致 系统运行缓慢，其实同样问题也适用于当初对EJB实体BeanCMP埋怨上，实体BeanDomainModel耐久化，如果不首先设计DomainModel,Hibern一个基于对象模型耐久化的技术。而是设计数据表，和耐久化工具设计目标南辕北辙，能不出问题吗？关于这个问题N多年就在Jdon争论过。
数据库是否需要在项目开始设计？这里同样延伸出另外一个问题：数据库设计问题。
那么就产生了一系列问题：当我使用Hibern实现耐久保管时，如果我进行数据库设计。必需考虑事先设计好的数据库表结构以及他关系如何和业务对象实现映射，这实际上是非常难实现的这也是很多人觉得使用ORM框架棘手根本原因所在
也有脑力相当发达的人可以 实现，但是这种围绕数据库实现映射的结果肯定扭曲业务对象，这类似于两个板块(数据表和业务对象)相撞，肯定发生地震，地震的结果是两败俱伤，软的一方吃亏，业务对象是代码，相当于数据表结构，属于软的一方，最后导致业务对象变成数据传输对象DTO,当然。DTO满天飞，性能和维护问题随之而来。
特别是ORM痛苦使用问题，关于ORM/Hibern使用还是那句老话：如果你不掌握领域建模方法，那么就不要用Hibernate,领域建模解决了上述众多不协调问题。对于这个层次的也许NoORM更是一个简单之道：NoORM:Thesimplestsolution
Spring分层矛盾问题
其本身拥有的强大组件定制功能是优点，Spring以挑战EJB面貌呈现。但是存在实战的一些问题，Spring作为业务层框架，不支持业务层Session功能。
需要将购物场所保管到Session中，由于业务层没有方便的Session支持，只得将购物车保存到HttpSession,具体举例如下：当我实现购物车之类业务功能时。而HttpSession只有通过HttpRequest才干获得，再因为在Spring业务层容器中是无法访问到HttpRequest这个对象的所以，最后我只能将“购物车保存到HttpSession这个功能放在表示层中实现，而这个功能明显应该属于业务层功能，这就导致我Java项目层次混乱，维护性差。违背了使用Spring和分层架构最初目的
领域驱动设计DDD
分层架构是使用Java根本原因之一，现在回到讨论的重点上来。域建模专家EricEvanDomainModelDesign一书中开篇首先强调的分层架构，整个DDD理论实际是告诉我如何使用模型对象oo技术和分层架构来设计实现一个Java项目。
当我执着于讨论各层框架如何选择之时，现在很多人知道Java项目基本有三层：表示层 业务层和持久层。实际上我真正的项目开发工作还没有开始，就是选定了某种框架的组合(如Struts+Spring+Hibern或Struts+EJB或Struts+JdonFramework还没 咳嗽吃什么药好的快有意识到业务层工作还需要大量工作，DDD提供了业务层中再划分新的层次思想，如领域层和服务层，甚至再细分为作业层、能力层、战略层等等。通过层次细化方式达到复杂软件的松耦合。DDD提供了如何细分层次的方式
可能忘记以何种依据选择这些架构技术？选择规范是什么？领域驱动设计DDD回答了这样的问题，当我将精力花费在架构技术层面的讨论和研究上时。DDD会告诉你如果一个框架不能协助你实现分层架构，那就抛弃它同时，DDD也指出选择框架的考虑目的使得你不会 人云亦云，陷入复杂的技术细节迷雾中，迷失了架构选择的根本方向。
其实DDD和设计模式一样，现在也有些人误以为DDD一种新的理论。不是一种新的理论，而是实战经验的总结，将前人 使用面向模型设计的方法经验提炼进去，供后来者学习，以便迅速找到驾驭我软件项目的根本之道。
因为它将着名的PoEA A 进行了具化，现在EvanDDD概念很火。实现了PoEA A 可操作性，这也是MF大力推崇的原因。最近(8月8日)一位老外博客上用微软的NET架构和EvanDDD比拟的文章：比拟了微软的三层服务应用架构[MicrosoftTLSA ]和EvanDDD架构，使用Microsoft.NETPetShop4为例子，解释两个目标的区别，并且标明微软是如何在案例中更好地实现支持后者。这篇文章协助哪些。NET平台上有域设计知识的人实现更好地提高。
本文由 婴儿用品专卖店 http://www.huazhuliu.com 整理转载
|
|
发表于 2012-10-12 15:19:26