由于系统有5000个同时在线,对应用系统来说,属于中,大型的系统了。
从单纯的系统架构来说,用下面4种都是可以的。
但做一个系统,不仅仅是架构,要既考虑系统的安全性,可靠型,稳定性,
也要考虑项目组的对这些组件的熟悉程度,以及项目开发的投入时间,人力等因数。
如果单纯从架构来说:
我个人觉得,如果公司已经有积累,架构1在开发周期上是最短,如果项目组已经确定在设计模型中确定了边界类,控制类,实体类.那么,边界类,控制类很容易建立和struts的映射关系,而实体类又可以用hibernate映射成数据库实现。那么基本上系统的结构就形成。但缺点是:hibernate不想EJB,在cache方面没有优势那么同时5000的访问,是否又问题,以及出了问题是否有强力的支持,这些都是项目风险。
我个人觉得:架够2是一个比较好的方式,即用了struts的MVC,又使用了hibernate强大ORM能力,同时也可以借助ejb容器强大的cache和安全,事务等的能力。。
架构3,我个人认为,这种方式处理大结果级的返回时候可以用,但全系统的应用是不理想的。
架构4:等于就完整的应用,应用服务器的功能来实现,中间可能再穿擦一些成熟的世界模式来处理性能问题,比如会话外观,值对象,复合实体等。但这个架够需要强大的设计,对程序员要求也高,同样和架够1,架够2有同样的问题,处理大量数据delte和update很不方便,同时在处理数据模型关系很复杂的结构时候,处理很麻烦。
以上是一点点观点,综合来看,其实在架够选则前,还有很多东西要考虑,以后系统业务需求的变化有多大,有可能要支持异构的数据库,是否有可能由于系统性能问题,需要迁移平台到商业化的平台等等。。。这都对架够设计有影响!
而且架够的设计也并不是就不能一呈不变,因为各有各的优势需要取舍,比如
cmp,hibernate对大量的数据delte,update就比较劣势。所以我们也许可以对这样应用直接用jsp+jdbc处理.cmp,和hibernate对大结果级的查询也有劣势,所以也可以改jsp+struste的标记库+sessionBean+jdbc
一点点心得请大家一起讨论!!!
架够1:struts+hibernate
架够1:struts+sessionBean+hibernate
架够3:struts+sessionBean+DAO+jdbc,加上cache功能(参考jive,apache的pool)
架够4:struts+sessionBean+cmp