凤舞凰扬的话

我这里阐明两点：一，我的观点不是说绝对不能传递PO到表现层，一个很简单的应用，如同Pufun所说似乎永远不会改（不需要移植，不会有太大的变更）的情况时（比如小的项目、个人demo或者公共系统等什么），的确可以这么做，丝毫不要拘泥于某种限制（在适当的情况下，goto都可以用），这些都是对的。但是一点，在讨论架构这个词眼的时候，就不应该提出这样的观点了。前面的只是策略，但绝对不是架构。第二，我是经历过这样的项目开发的，不是像有些朋友说的我好像是空白谈书似的，如果有朋友知道的话，可以了解了解同望公司（交通行业最大的软件商）的系统，可以这么说，直到现在，他们也许还是这样做的。（我本不应该这么直接的说出，但是我只是想如果有同望的朋友，可以看看，可以总结），没有这样的经验，我何来如此反对？楼上有些朋友，我真敢说，你们绝大部分中做实际大项目的经验没有我丰富，我不是自吹什么，没有必要，现实中也见不了面。我只是希望我们能相互吸取知识和经验！

最后，我给大家解释一下什么叫架构。架构（achitecture）来自于建筑学的概念，是框架（framework）和结构（structure）的合称。其中它与框架的区别主要体现在，它着重描述各个框架中的结构关系（之间的组合等），描述框架间的联系，突出它的结构特点。一个好的架构师或者设计人员必须对框架，框架的组合有非常清晰地认识。架构不会被框架中的组成所绑定所限制。软件系统的架构又体现在什么上面？也就是你所做系统所选择的框架，框架的组合，框架间的通信（包括协议、数据表示、接口联系等）。好，我结合楼主讨论的题目说说为什么不能在架构中表达这样的概念。首先一、用一种数据对象来维持多个不同框架间的数据联系，使所有框架相互绑定死，那么自然就根本没有体现出框架间联系的方式，根本就谈不上任何架构；二、楼主的PO来自于什么？hibernate还是其他，如果是hibernate，那么你的架构就限定于框架的选择（简单地讲就是一栋楼的设计限定于一层房子的结构），这还算架构设计么？如果是JDO、CMP，这样的PO还能不能传那？三、一个好的架构是怎么评估的，应该是可扩展、易维护，高容错，而不是所谓的一些性能的损失（它是放在后面的）。有些东西，看来的确不会出现，但是在架构设计中不能不考虑（就简单地如同，在非地震地区建的楼房依然要达到一定的防震等级），架构的设计，应该是就架构设计人员及相关业务人员的水平，充分评估系统存在的可能性。比如将数据库的更改（有人说数据库的更改是业务的更改，这是一个典型的错误，设计的更改往往是分析设计人员对需求把握挖掘不够），就会给楼主的选择方式带来灾难性的破坏，这样的非容错，难扩展的架构还能叫什么架构么？大家想想戴高乐机场给我们带来的启示吧（软件系统的灾难就是需要大投入大范围的重构）！

架构和MVC是两个完全不相关的概念，MVC是用来构建用户界面的一种思维，或者可以理解为一种模式，Struts以及各种web框架都是体现了这种思维，但是它和架构是两码事。我们可以说web框架是基于构建J2EE应用的重要组成部分（但并不一定，比如你可以用web service）。
轻量级的东西能帮我们做什么？当然，它可以为我们解决不少问题，能够快速地构建一个系统和应用，但是说，在讨论一个架构这样词眼的时候，动不动就被这些框架这些组建所困促，觉得有些什么呢？难道大家做的系统就为hibernate而生？举一个有些不负责的例子：你们可以到JDON上看看，有篇文章是IBM的一位工程师留的，他说他们的系统开始准备用hibernate,但是客户要求IBM负责使用hibernate带来的问题，IBM不愿意承担，所以最终没有使用。任何一个框架都存在缺点，就连整个java one组织开发的EJB都存在，何况一个hibernate,把它吹成神一样，是否有些过了？哪个敢说它就没有一点问题？（我们要使用它，但是绝对不要依赖它）
我不是动则谈大应用，动则就是大概念。但是首先我们谈的就是架构，比如建造，我们能对一个小楼房去谈它的架构建造么？多层，不是说，你描述一个多层就是多层了，不是说你简单地把程序分割开就是多层了，架构，不是说你把Struts+Spring+Hibernate拿来用就是架构了，不是说只是简简单单地结构关系就是架构了，他们仅仅是简单结构的一种堆砌。真要那么简单，个个都可以做架构设计师了。
争了这么多，也应该结束了。我希望各位朋友站高一点，看远一点，当你们系统不依赖于任何一个数据持久层，发现hibernate好可以移植hibernate，发现EJB好可以移植EJB等等的时候，那么你可以对自己说，你的架构日趋成熟了。

评论

1 楼 fengjingxianjing 2015-01-13