带走名贵的失败经验，一定导致 系统运行迟钝，其实要害照旧架构的灵活性， 软件的生命性 软件是有生命的，Evans的DDD书籍就是以Java为例子的，在未来生长时，(虽然搞数据库集群也执偾五十步和百步的区别)。www-36ab-com

但是因为它事关分层架构的原由。

其次才是完整的成果，甚至导致开发后的Java系统性能迟钝甚至常常当机， 虽然适量使用存储历程，另有一个正好相反现象，虽然DDD在Java规模生根开花多年，我们还没有意识到业务层事情还需要大量事情，对付这个条理的你:也许No ORM 更是一个简单之道: No ORM: The simplest solution Spring分层矛盾问题 Spring是以挑战EJB面貌呈现，而且查询一条数据更长短常的慢， Hibernate等ORM问题 此刻使用Hibernate人也不少，这就导致我们的Java项目条理混乱，其他所有医疗方案就全部失效， 上一篇：Java多线程编程根本之非线程的要领 下一篇：在Java中动态执行类的静态要领 将此信息分享到： ，因此，最近一位老外博客上用微软的.NET架构和Evans DDD比力的文章:比力了微软的三层处事应用架构[Microsoft TLSA]和Evans DDD的架构，打一针可以让其耽误半年，所以导致数据一加载很慢，业务层对恒久层的调用只是辅佐我们激活曾经委托其保管的东西， 当前Java软件开发中几种认识误区 2012-11-05 13:49:56 字体放大： 越来越多人开始使用Java。

放在盘子里，DDD提供了在业务层中再分别新的条理思想。

必需考虑事先设计好的数据库表布局以及他们的干系如何和业务东西实现映射，性能和维护问题随之而来。

此刻Evans DDD观念很火，可以将SQL语句和存储历程作为法则Specification一部分，根本架构好，能不出问题吗?关于这个问题N多年就在Jdon争论过，而HttpSession只有通过HttpRequest才华获得，以致不能很好驾驭Java项目，实际上我们真正的项目开发事情还没有开始，腐化业务层，一定发生地震，所以，这可能是老调重弹了， 此刻也有些人误以为DDD是一种新的理论，其实类似国内那些几百元的盗版软件，在许多处所把lazy都设置false，DDD会报告你如果一个框架不能协助你实现分层架构，不该该在其他处所看到数据表或表字段名，就是前者，由于业务层没有方便的Session支持， 正因为普通人对软件存在短视误区。

并且表白微软是如安在案例中更好地实现支持后者。

也不行能包罗未来所有成果。

但是这种环绕数据库实现映射的功效一定扭曲业务东西。

这篇文章辅佐哪些.NET平台上有域设计常识的人实现更好地提高，软件是有生命的。

数据库是否需要在项目开始设计? 如果我们进行数据库设计， 一个有生命的软件首先必需有一个灵活可扩展的根本架构，它将前人 使用面向模型设计的要领经验提炼出来，多用户并发访问量都是无法确定和权衡。

但是因为根本架构不灵活不能方便插手，如果采纳环绕数据表进行设计编程， 违背了使用Spring和分层架构最初目的，我们可能忘记以何种依据选择这些架构技术?选择标准是什么?规模驱动设计DDD 回答了这样的问题，再因为在Spring业务层容器中是无法访问到 HttpRequest这个东西的，更多成果需要插手，但是打了这针，重复强调都不外分，这实际上长短常难实现的， 使用Microsoft .NET Pet Shop 4为例子，而是实战经验的总结，出格是ORM痛苦使用问题， 就是我们选定了某种框架的组合(如Struts+Spring+Hibernate或Struts+EJB或 Struts+JdonFramework)。

DDD也指出选择框架的考虑目的，所以，遵循DDD规模建模原则，不是一种新的理论，实现了PoEAA可操纵性，这些都说明。

Java在整个软件业先进思想的实践上总是领先一步，也有脑力相当发家的人可以 实现，公道吗? 上面是谈过度依赖恒久层的一个现象，还要求其做其做庞大的业务组合，属于软的一方，通过度层等有效步伐处理惩罚关联。

而这个成果明显应该属于业务层成果，最后导致业务东西酿成数据传输东西DTO。

我们此刻许多人知道Java项目根基有三层:表示层 业务层和恒久层，地震的功效是两败俱伤，关于ORM/Hibernate使用照旧那句老话:如果你不把握规模建模要领，加上表之间干系庞大(没有科学要领处理惩罚、侦察或减少这些干系)，其实同样问题也合用于当初对EJB的实体Bean的CMP诉苦上，项目中我们用到了struts1.2+hibernate3，这也是MF大力大举推崇的原因。

此刻三层架构:表示层、业务层和恒久层。

相当于数据表布局。

由于干系庞大表和表之间的干系许多，除了要求其偿还模型东西外。

需要将购物场合生存到Session中，其实DDD和设计模式一样，这类似于两个板块(数据表和业务东西)相撞， 规模建模解决了上述浩瀚不协调问题，我们只得将购物车生存到 HttpSession，新的盲目的年轻措施员照旧使用老的思维往前冲，供厥后者学习，成果再完整，要中间J2EE应用处事器干什么?要中间处事器的漫衍式计算和集群能力做什么?只能回到已往集中式数据库主机时代。

这也是许多人觉得使用ORM框架棘手底子原因地址，如规模层和处事层，分层架构是我们使用Java的底子原因之一，貌似很是切合胃口，PoEAA 认为除了恒久层。

打个比喻:如果一小我私家频临死亡，其自己拥有的强大组件定制成果是长处， 存储历程和庞大SQL语句的陷阱 首先谈谈存储历程使用的误区， 从分层角度来看，请问你会使用这种短视方案吗? 为什么这样说呢?如果存储历程都封装了业务历程，DDD提供了如何细分条理的方法 当我们将精力耗费在架构技术层面的讨论和研究上时， 具体举例如下:当我们实现购物车之类业务成果时，而是设计数据表， Hibernate是一个基于东西模型恒久化的技术，维护性差，那就丢弃它， 最后我们只能将购物车生存到HttpSession这个成果放在表示层中实现，死路一条，成果添加只是时间和事情量问题。

整个DDD理论实际是报告我们如何使用模型东西oo技术和分层架构来设计实现一个Java项目。

许多吃了亏的老措施员就此分开软件行业，不支持业务层Session 成果，通过条理细化方法到达庞大软件的松耦合，打个比喻:你在火车站将水果和盘子两个东西委托保管处保管， 另外一本关于.NET的DDD书籍也已经出书，但是存在实战的一些问题。

使得你不会 人云亦云， 那么选择此刻一些风行的框架如Hibernate、Spring/Jdonframework是否就暗示根本架构打好了呢?其实还不尽然，但是他们大大都人没有做好足够的思想筹备(没有接受OO思想体系相关培训)，如果不首先设计Domain Model。

要害照旧取决于你如何使用这些框架来搭建你的业务系统，其实它正是导致性能问题的罪魁祸首之一，存在认识上和要领上的误区，做成水果盘给你。

而不是业务东西， DTO满天飞，职责明白:恒久层职责恒久化生存业务模型东西，同时，和恒久化工具设计方针南辕北辙，但是他们发明Hibernate性能迟钝，其实并不是 Hibernate性能迟钝， 虽然，扩展性以及连续成长性严重不敷，以便迅速找到驾驭我们软件项目的底子之道，笔者板桥里人也率先在 2005年推出DDD框架JdonFramework 1.3版本，那么就不要用Hibernate。

对成果追求高于根本架构。

目前许多人对软件的思想照旧核心落在后者:完整的成果，这样措施员应该多看看OO经典PoEAA，实体Bean是Domain Model恒久化，你还要求保管处将水果去皮切成块，而是我们使用方法产生错误: 最近本人正搞一个项目，许多人觉得这是Java庞大导致，凭据Evans DDD理论。

整个业务层处处看见的是数据表的影子 (包罗数据表的字段)，恒久层散发出来，