不要让开源架构代替我们的设计

    现在开源的各种framework非常的多。干什么的都有。但是，是不是我们使用了这些开源framework就能够一劳永逸的解决我们的设计问题呢？我觉得答案是否定的。如果没有自己对设计和系统的理解。框架滥用就在所难免。比如说hibernate（以下简称HI），它是一个对象持久框架，他的目的非常的简单，就是提供对象持久化的手段。但是在日常的工作中，我经常看见很多人把HI用的非常的复杂，希望用HI实现一些复杂的数据库查询，似乎把HI看作了一个数据库抽象层了。使用HI，却永远不忘记SQL。我觉得这是不正确的。虽然HI的本质是ORM。但是它可不是用来替换数据库的。不要把HI当作数据库一样去操作。在设计的时候要考虑对象的差别，那些是业务对象，那些本身就是数据。如果本身就是处理数据的话，我们可以使用criteria这样的数据操作封装来操作数据。甚至，直接使用SQL语句，这时候我们的视角就发生了变化，不在是停留在业务对象上了。数据就是数据不要往对象上靠，这样更好。动不动的就搞一个POJO可不是一个好的习惯。另外，如果我们是对原有系统进行改造的话，推荐使用cayenne，apache的开源orm，有自己的管理器，可以自动从数据库中同步出pojo来。

    如果是我们自己从头开始设计系统，建议不要再在数据库里面指指戳戳了。把数据库表之间的关系，改为对象之间的关系，自己写程序来维护自己对象之间的关系，推荐使用di（依赖注入），不用也可以，关键看你系统的规模。数据库中的表要尽可能的简单，要分维度和事实，以便于复用并（建议大家了解一些数据仓库的概念）减少表中的字段数。如果你采用多维结构来设计数据库的话，表中的字段不会很多。设计的好坏完全凭你多年的经验和对客户系统的了解。（分析出那些是维度，那些是事实，不是一个容易的事情，做过的人都知道）

    对于框架的应用，我本身都是非常慎重的。如果我们不理解这些框架的使用背景，使用这些框架，就难免产生各种各样的问题。那么，好与不好的原则是什么？我觉得《Better, Faster, Lighter Java》一书的作者说的很好：Keep It Simple、Do One Thing,and Do It Well、Strive for Transparency。翻译过来就是：保持简单、一次做好一件事、力求透明。其实一个好的框架最起码要做到的就是透明性，有些人也管它叫非侵入性。比如spirng。（spring因此遭到批评说它其实什么也没有做，这个我有所同感）其实侵入性不是框架的问题，是我们自己设计的问题。我们应该在我们的设计中对引入的框架部分做我们自的接口，这样就可以摆脱框架侵入性的困扰。

    最后我想说说我心目中的先进的web应用框架应该是什么样子的。首先它一定是REST的，所有的东西都是资源，这样可以避免session的烦恼。其次，它一定是面向服务的，也就是所谓的soa，这样可以实现松耦合，并且可以实现类似组件的功能。view部分一定是ajax的，但是也要组件化，现成的方式是EXT+buffalo。但其实也可以使用其他的界面方式，比如net 的winform或者java的swing。最后还有一个对象管理器，专门负责业务对象的管理。透明的采用aop的方式，把日志、任务、权限、事物、工作流，集成进来，各个部分都是独立可配置的。可以根据需要将它们配置进我们的应用中。最后提供一种分布式的解决方案来应对可伸缩性。另外根据约定，尽量减少配置的数量和次数，尽可能的提供配置工具，而不是我们手写XML配置文件。

评论

19 楼 lakemove 2008-05-08  

引用

我们应该在我们的设计中对引入的框架部分做我们自的接口，这样就可以摆脱框架侵入性的困扰。

为什么不把sping看成自己的框架呢 ?

18 楼 clarkhill 2008-05-08  

    看到有人说我对hi的理解有问题。汗一个。不是我对hibernate的理解有问题。我是见过有人把hi当成数据库来使用，我才这么说的。本来使用ORM的目的是改变我们的设计方式，抛弃以往的以数据库为中心的，数据库紧密依赖式的设计。但是有多少人真正这么做了？很多人就算是用了orm，还是先去画数据库的er图，搞得复杂无比，关系杂乱。根本就没有oo的设计思想。如果你用过db4o这样的对象数据库就明白我的意思了。

17 楼 slaser 2008-05-08  

晕倒，我们是产品的公司，我们的产品确实需要在不同数据库上跑，这个是需求。我们怎么操淡心了？不是每个公司都买得起oracle的

16 楼 laiseeme 2008-05-07  

lz对hibernate的认识有些不敢苟同
orm就是为了在关系数据库和面向对象的语言之间建个桥梁,如果数据库也oo了那何来orm

15 楼 tongue 2008-05-07  

sslaowan 写道

mcpssx 写道

我心目中最好的web应用框架，就是PHP式的一通乱写，

最烦唠叨什么XML可配置，

分一堆层可维护，

还有什么可伸缩
，
数据库可移植（所以不要用存储过程）。

真是操淡心

显然是没做过大型复杂的企业应用啊

那把你做过的“大型”“复杂”的“企业”应用show一下，让我们这些没见过世面的也见识见识。

14 楼 october731 2008-05-07  

学习  学习

13 楼 lelong 2008-05-07  

应用成熟的框架，可以提高开发效率和加强可维护。
但是为应用框架而用框架，而是想着框架可以帮你解决什么问题

12 楼 supercode 2008-05-07  

灵活，高效，可维护，可扩展
软件设计是个取舍和平衡的问题

11 楼 lgx522 2008-05-07  

用不用框架，用什么框架，要由具体的系统来决定。

比如说是互联网应用还是企业内部应用，需求变动快不快，业务关系有多复杂，读为主还是写为主，数据量有多大，访问量有多大，响应速度要求有多高，布署的方式和规模如何，异构集成的要求有多少，统计报表的要求有多高，给多少钱，做出来有什么用......
一大堆问题，搞清楚再决定用什么技术、什么框架才可以满足需求。

10 楼 troyconder 2008-05-07  

有道理 过度设计其实最大的麻烦是浪费大脑。

9 楼 sslaowan 2008-05-07  

mcpssx 写道

我心目中最好的web应用框架，就是PHP式的一通乱写，

最烦唠叨什么XML可配置，

分一堆层可维护，

还有什么可伸缩
，
数据库可移植（所以不要用存储过程）。

真是操淡心

显然是没做过大型复杂的企业应用啊

8 楼 Norther 2008-05-07  

没有人把hibernate当作数据库，hibernate的目的不是简单的持久化对象，java的serializer也可以持久化对象，hibernate是什么请先google，hibernate不是面向对象数据库，只是ORM工具，ORM工具就是这个样子，ORM和关系数据库的关系不是互相替代，怎么可以说用了hibernate就替代数据库？没有关系数据库要ORM干虾米？开源框架影响设计，那是因为你对开源框架认识的还不足，个人认为楼主的对于这些概念的理解过于浅，建议先补充一下相关的知识。

7 楼 icefire 2008-05-07  

刚开始--简单--搞分层--感觉像自虐
需求膨胀--复杂--希望分层--清晰，好维护，可复用。

PHP的红火，个人觉得是由于自由，没有约束。
JSP也可以很自由，但Java的大环境让你不自由。

框架只是工具，分离关注点，不过现在却让人太过去关注框架。
其实PHP框架也很多了，不过一般入门书籍不讲这些。

要是10行代码能解决问题，我也不想为了分层而写30，40行。

其实hibernate的理想状态应该是db4o那样子。

6 楼 xellos 2008-05-07  

mcpssx 写道

分层也好，伸缩性也好，只为了一个目的，就是提高系统的性能。

分层是为了性能?你真的这么觉得吗?没觉得是略微牺牲性能换来可维护性?

mcpssx 写道

数据库可移植？不知道这是谁想出来的理由。。

数据库可移植性只是举一个例子来说明有时候这种情况是"假想需求",举例子你懂吗?

mcpssx 写道

另外，一个清晰的架构，简单易用的配置是为了今后的维护方便，为企业搭建信息系统不是一锤子买卖，系统上线并非一个项目生命周期的结束，今后不断的升级、维护在等着你，而且以后的维护和升级人员并非是最初的创作者，你必须考虑怎么让他们尽快了解你的系统，

你是大学老师吗?整这么多理论,你不觉得太初级了吗,我想这个论坛没有谁不知道这些.你这种行为就像是到处给别人讲 1+1=2 一样.
人家提到PHP了,你还跟这讨论"为企业搭建信息系统"呢.你见过用PHP做企业信息系统的吗?
PHP是互联网应用的王者,暂时它的地位还很稳固.
你了解PHP吗?知道它的优点在哪吗?你是不是觉得它像MS的asp一样该退出历史了?
层次,架构,是为了降低维护成本.这是句废话.
说的是有时候不要过度设计,陷入假象需求.听过"过度设计"这四个字吗?
知道"在一定程度上有道理",和"有道理"的区别吗?

mcpssx 写道

一个成功的设计不是给开发人员的，而是给维护人员的。

貌似有道理的一句话 ,你仔细想过吗? 成功的设计会考虑可维护性,但是前半句,"不是给开发人员的"就对了吗?

mcpssx 写道

体会不到这一点，因为你的项目缺乏持续性，基本都是一锤子买卖。

就事论事,就理讲理就得了,对什么"你的项目如何如何,体会不到什么什么"这种指手画脚干什么?
整的跟 你多有经验似的?

5 楼 buaawhl 2008-05-07  

个人意见.

POJO就是为了达到非侵入性的目的.

自动从数据库中同步出pojo来,如果是代码自动生成,那么也是一种侵入性.
如果数据库结构改了,代码就要重新生成,代码里面写的业务逻辑(Domain Method)怎么办?还是需要copy.如果强制不能在数据对象中写domain method,那么就失去了POJO的优越性.

使用criteria这样的数据操作封装来操作数据。
这也是一种侵入性, 相当于把 Java API 侵入到了 SQL / HQL 的领域.(反向侵入)
SQL/HQL的可读性更好,更加适合描述表达查询语句.
criteria的可读性就差了很多.也蹩脚了许多.
比较好的方法是把所有的HQL/SQL都从Java代码中分离出去,放到单独的资源文件中.统一管理操作.

4 楼 juliashine 2008-05-07  

xellos 写道

mcpssx 写道

我心目中最好的web应用框架，就是PHP式的一通乱写，

最烦唠叨什么XML可配置，

分一堆层可维护，

还有什么可伸缩
，
数据库可移植（所以不要用存储过程）。

真是操淡心

一定程度上讲,你的观点非常有道理.
很多情况下,有很多人陷入了过分的"假想需求"之中.

有的公司做产品,要能根据客户的需求定制,所以人家的"产品"有了数据库可移植的需求.
又出来一帮子公司,看到上述公司的东西可以移植数据库,于是他们也做.但是他们根本就是扯淡.

纯属扯淡。分层也好，伸缩性也好，只为了一个目的，就是提高系统的性能。数据库可移植？不知道这是谁想出来的理由。另外，一个清晰的架构，简单易用的配置是为了今后的维护方便，为企业搭建信息系统不是一锤子买卖，系统上线并非一个项目生命周期的结束，今后不断的升级、维护在等着你，而且以后的维护和升级人员并非是最初的创作者，你必须考虑怎么让他们尽快了解你的系统，一个成功的设计不是给开发人员的，而是给维护人员的。体会不到这一点，因为你的项目缺乏持续性，基本都是一锤子买卖。

3 楼 Godlikeme 2008-05-07  

觉得lz对系统的理解还很理论化，想法不切实际。
而且文不对题。

2 楼 hsq972 2008-05-07  

xellos 写道

有的公司做产品,要能根据客户的需求定制,所以人家的"产品"有了数据库可移植的需求.
又出来一帮子公司,看到上述公司的东西可以移植数据库,于是他们也做.但是他们根本就是扯淡.

非常认同这一句.不说产品,就项目而言,一般公司花高价买进的oracle没五六年是不会大升级版本的,更别提换DB了.

1 楼 xellos 2008-05-07  

mcpssx 写道

我心目中最好的web应用框架，就是PHP式的一通乱写，

最烦唠叨什么XML可配置，

分一堆层可维护，

还有什么可伸缩
，
数据库可移植（所以不要用存储过程）。

真是操淡心

一定程度上讲,你的观点非常有道理.
很多情况下,有很多人陷入了过分的"假想需求"之中.

有的公司做产品,要能根据客户的需求定制,所以人家的"产品"有了数据库可移植的需求.
又出来一帮子公司,看到上述公司的东西可以移植数据库,于是他们也做.但是他们根本就是扯淡.