Dojo
话题
新佳
订阅
极道
元认知
元逻辑
元设计
元编程
元语言
Java程序分层架构
解放思想,走出传统三层架构的束缚
05年底的时候,我们项目组要开发一个ERP的系统。我们选择了jsf(ADF)+spring+hibernate的架构进行系统开发,3层分层架构进行设计开发。技术经理把表设计好,跟我们讲清楚表和表之间的关系,然后我们写model,dao,manager,form来实现。那时候我根本没有什么面对对
系统为什么需要分层?
在日常的软件开发当中,我们一般都是采用了分层的方式来架构系统,但是为什么我们需要分层进行架构呢?在此之前,我觉得需要搞明白两个概念,什么是软件的伸缩性,什么是性能。 首先,什么是软件的伸缩性(Scalability)?我们都知道设计良好的系统
请问一下这样分层对不对
现在做一个系统,框架就用spring 打算这样分层 dao:只负责数据的持久化以及查询 cache: 领域对象存放的地方 repository:数据的入口与出口,负责保
DDD,SSH...希望bang和各位高手指正我的理解误区?
一直也对JAVA EE层次架构非常感兴趣,用SSH开发居多,对于DDD的概念,真的没有听说过,看了大家很多的文章,也看不明白,或者真的要静下心来,买本书来好好学习学习。 我的理解是分层的层次有:表示层+业务逻辑层+数据库访问层, 表示层对于于MVC模型,struts1.x中的JSP
架构中的分离
我的一个项目中,引入了一个类似ddd的分析,然后跟兄弟们就搭手创建,实现代码!但是,在我们创建的过程中,以及不断的分析中,我们发现全部按照ddd来实现有很多比较牵强,或者说是有点复杂化了,在此表述出来跟同行的xdjm们探讨探讨。我们从最开始就用ddd的模式进行业务分析,找出其中的业务
关于java的三层架构存在的疑惑
首先,本人对架构的概念比较肤浅。以下只是通过大大小小的项目一些问题总结,希望能引起大家的共鸣,并得到很友好的回答与支持。 java项目一般分为三层:表现层,逻辑层,数据层.其中表现层基本用开源框架(struts2)其中逻辑层通过spring
一个常见但不是那么容易的架构问题
很多互联网或者企业系统,都是前面一个线上运营系统,后台一个内部管理系统,共享一部分库表数据,各部分都是运行在各自不同的进程,比如s2sh系的,打开hibernate缓存,那么运行在不同进程内的各运营子系统之间,以及与内部管理系统之间,如何既能利用缓存,也能避免数据脏问题。我们现在是用消息弥合的,但有
说说三层架构和MVC
发现不少工作很多年的人的看法也不一,不知道这里能否找到一个权威点的说法?
关于领域模型与分层问题
大家好,现在我有点不太明白领域模型与服务的问题,领域模型是不是应该有行为,也就是说应该有的职责与业务逻辑,那么服务是做什么的呢,做事务和调用仓储么。还有业务逻辑与领域逻辑是一回事情么。现在觉得服务层有点多余,实在不清楚他负责什么,可领域模型有不能注入仓储类似其他东西,都要用Domain Event进
层次架构的困惑
介绍一下项目的现状先: 大体介绍:表示层使用JSP,控制层使用STRUTS2,业务逻辑层使用自己封装的service类,持久层使用SPRING的JDBCTemplate封装SQL。 我现在的调用流程是这样
j2ee的分层模型问题(第一次发贴!!)
一直在用j2ee的分层模型(表现层、业务层、持久层),但是对其是一知半解,那位高手说说这个东东的渊源,是j2ee规范中提出的吗?推荐点比较权威的资料看看。还有他和MVC的区别??如果有高手回答,鄙人十分感谢。
关于分层结构的参数传递形式
比如一个高级查询界面提供很多查询条件(假如我们的分层是:表现层-应用层-领域层-基础设施层) 那么首先表现层会调用应用层:findByPage(参数...),应用层的findByPage也会调用基础设施层或者领域层的findByPage返回结果,这时候就涉
网站出错,请教高手,显示连接已经满了
最近,负责老的网站维护,全是JSP写的!!!! 运行一段时间,就死了!!! 显示配的数据库,连接已经用完!!!Cannot get a connection, pool error Timeout waiting for idle object
JdonFramework web框架整合
使用jdonFramework 整合web项目时只能用struts,jsf这些,其他类型的可以使用他吗?
系统中的User角色和Domain的说法
在一个系统中有domain部分,同时UI其实在系统内,应该有个User用户的对象。 UI ---发送命令---> User#method -----> 方法内部调用 domain
寻求企业解决方案,特请各位老大指点.
我是零售企的程序员,主做c/s架构的开发。我们目前的crm系统是用delphi开发的,客户端直接访问数据库,但随着数据量的几何增长,数据查询变得十分缓慢,特别是海量数据查询。目前的解决方案是不断提升服务器硬件,但这投入太大了,所以想改一下软件架构。特别是看了论坛的《数据库已死》这篇文章后,感触
小项目开始未分层,但后来业务复杂,如何改进?
以前写java,一直是数据层,业务层,表现层,这么写。最近用到.net,开始很生疏,感觉.net的框架发展还不是很成熟,orm框架也不敢用,不熟悉。 想自己写实体,但是又麻烦,每个数据表一个类,类的封装也很麻烦,比如表30个字段,页面来的数据我要set30次,构造成对象,然后传
关于分层
我们都讲到MVC分离,可是分层确实是很难做到的如页面上数据的现实问题,这些显示当然是业务层的体现,不可能脱离业务层,现在业务层要求能对显示层的控制就是根据不同的用户显示不同的结果,而这个结果是一个可选的,如同一个业务逻辑有的要显示10个数据项,有的只需要现实6个数据项,我们是在业务层只提供6
上页
下页
关闭