Java程序分层架构

现开发的项目，持久层：hibernate业务层：spring表现层：没有使用什么struts框架，使用了本公司的一个框架，并且JSP中使用的C标签。 现在拿页面数据的保存和显示，来说一下我所要请教的问题。一、背景环境：

在Struts中action是处理业务逻辑的，如果加一个service层是不是有点多余啊？而加一个service层又有什么好处呢?[该贴被taotaob于2009-03-01 09:29修改过]

在看MF的《企业应用架构模式》，提到现在流行的分层结构 表现层-领域层-数据层 这是否对应MVC的V C M？？ 让故事回到刚开始学JSP的时候，我看得第一本书讲JSP和MVC，采用最原始的JSP向Servlet发送请求，Servlet封装数据将数据传给D

讨论--------分层架构 用户界面层： 负责向用户显示信息，并解析用户的命令。... ---------这里的用户界面层是不是 jsp 一类的 view

在我理解业务对象是一个系统的基础，就像盖房子中的砖头，砖头的形状变了搭建房子的方法也就改变了，同样业务对象的结构改变了，系统的架构和设计也就改变了。所以应该是设计的基础。再来说DTO，字面理解看，data transfer object，数据传输对象，我理解主要是在多层开发的时候，各个层次传

我是一个大学生，大二了，用了很多时间学习j2ee，我现在只知道在写一个DAO接口，然后实现它DAOImpl，然后再Servce里面调用DAO接口，在action或者servlet里面通过一个Service工厂调用Service。我想知道到底j2ee是怎么样分层的？

小弟目前的系统架构如下:SSH框架搭建 首先是持久化层,有一个Service接口,里面有SaveAnything(Object ob){}QueryAll();等通用的方法.这个接口用于满足持久化的一系列操作.ServiceImp类

我中间层打算这么设计。架构采用Spring+Hibernate。创建中间业务层的接口A。然后建立代理类B和实际的业务处理类C。B和C继承A。B是C的代理。由表现层通过B去调用C。业务基本上都是执行HQL语句，所以还需要再建议一个Dao层吗？还是直接在C里写。如果再建立一个Dao层的话，C里基

关于贫血模型 贫血模型的问题与所谓专家原则以及分层原则直接相关。面向对象系统的主要任务就是安排对象系统的责任划分以形成合理的协同关系；专家原则是说，某个功能、行为应该分配给持有相关信息最完整的对象；显然，专家原则与关于高内聚的思想相一致。分层原则是就系统的大结构而言，企业级应用以业务逻

结构：Com.news.dao: NewsDAOCom.news.dao.impl: NewsDAOImplCom.news.dto: NewsCom.news.service : NewsServiceCom.news.servlet: AddNews,De

我对web工程的分层如下 dao 数据访问接口 成员: 接口,接口工厂类DaoFactory,公用dao类BaseHibDao dao.impl 数据访问实现 成员: 实现dao接口并继承BaseHibDao的实现类enti

今天写代码的时候，突然发现有一个service只是在传递action的调用到dao中，然后返回dao的执行结果到action中，其中service并没有其它业务逻辑。觉得这个service是不是冗余了？如果去掉该service，并不影响这个功能的实现，可是如果去掉了，它就破坏了代码的结构，编程act

刚看到你这篇文章： 一个小的

偶还在j2ee学习阶段~~关于分层,又迷茫了 1.使用Hibernate框架,老师说hql语句也属于业务部分,应该放在业务层(BO和service,即模型和模型的服务方法)的service那一部分,但这样我总觉得很别扭,之前做了一个项目练习,sql

最近自己构思一个web项目，在做DAO层的时候，想做成对上层（业务核心层）只暴露接口，但是接口的实现都是在DAO层里做，DAO层可以理解成一个独立的项目，也就是实现是封闭在这个层次中的，但是不太清楚JAVA能不能实现这样的想法，我记得在oracle的ADF框架中是可以实现的，是不是利用protect

工司以前开发的OA系统,是这样的.DTO,做持久层,与表现层,对象!是不是职责过多了,违反面像对像单一原则了!DAO丢弃了!service层是这样的,serivceinterface,serviceabstract,serviceimplbanq大G,说说看!我看到这