`

facade层,service 层,domain层,dao 层设计

阅读更多

一,Service->DAO,只能在Service中注入DAO

二,DAO只能操作表单数据,跨表操作放在Service中,Service尽量复用DAO , 

       只有一张表产生的业务放入DAO中。

三,事务操作,放在一个DAO中。

四,如果有更大Service的之间的复杂调用,考虑在service上再加Facade层 

  (Components组件)。

五,多考虑这部分代码放在哪里,多利用上下分层 ,增加代码可读性,提高代码复用率。

服务层处理业务逻辑,DAO封装Entity对象,Action作为Controller处理分发。
业务逻辑是最容易变化的地方,当业务改变时,只增加修改相应的代码即可。真正享受分层带来的益处。
 
 J2EE分层设计是Java企业应用的最基本的设计思想。

  从最常规的分层结构来说,系统层次从上到下依次为:

  表现层:主要是客户端的展示。

  服务层:直接为客户端提供的服务或功能。也是系统所能对外提供的功能。

  领域层:系统内的领域活动。

  DAO层:数据访问对象,通过领域实体对象来操作数据库。

  其中有些指导原则

  1、上层总是依赖其下层,依赖关系不跨层。

  2、表现层除外,同一层之间方法不允许相互调用 。这是实际开发中一些开发

    者容易范的错误!如果真是同一层之间存在方法调用 ,需要注意,这些调

         用都是一些上层不可见方法 ,比如一些工具方法等。

  3、一切从服务层出发 ,从系统需要提供的功能进行分析,确定Service接口中

          的方法 。而不是从数据库的表出发,创建DAO,再创Domain,然后

          Service,这实际上是对系统分层的误解。

  4、系统最核心的设计 就是将系统中的实体划分为领域模型 。在此基础上设计

          数据的DAO层,并将这些活动暴露给服务层,服务层的实现依赖于领域活

          动。

  5、每个接口的职责范围明确有界。

   在我所做的系统中,常常看到一些糟糕的编码:系统设计从表开始,一个表对应一个DAO,一个DAO对应一个domain,一个Domain对应一个 Service,实际上Service的接口和DAO的接口基本上完全一样!导致Service的接口方法超多!到了表现层,前台程序员在写Action 的时候,Action中反复的调用Service方法,代码不堪入目。

  正确的设计 应该是,一个领域活动会聚合对应一个或一组 DAO ,来完成一个领域活动。而一个服务可能包含两个领域活动 ,比如一个转账的业务,对应两个领域活动。两个帐户的金额分别发生变化,需要操作一组领域活 动,而每个活动需要操作很多表(调用多个DAO)。 事务的控制我们可以放到Service层。

  目前,越来越多的架构师喜欢领域模 型驱动设计 ,针对系统的领域模型建模,然后上层直接是Service,Service下面就是领域活动层 Activity,从而去掉了DAO层 ,这样做的 优点 是系统设计思路更清晰,目标更明确。可以避免上面所说的一个表对应一个DAO、Service的情况。

  但缺点 是当领域活动发生变化的时候,会引起领域活动层代码的变化。并且,当要更换持久化框架或者技术时候,领域活动要重新实现。

  但综合考虑起来,这样带来的优点也很多,而实际上更换数据库和持久化框架的情况很少,因此这样的设计也是有其合理性一面的。这样做实际上是将原来的DAO和Domain层合并为一个Activity.但上层的设计思路还是一致的。

  其实Service层的设计也很讲究,其中就是要控制Service的数量,从Service层往下,接口数量逐层增加。通常将一个模块的服务都集中到一个Service中来处理。

  每层中的每个接口都应该关注的是自己的那一块,而不是吃着碗里看着锅里,牛槽伸出个狗舌头,最典型的例子就是一个DAO中胡乱操作别的表。这种凌乱的实现只会置项目经理与死地。也会为软件的维护带来很大代价。

  笔者曾遇到这样的团队,缺乏对整个项目的整体设计,一个表一个DAO,对应一个Service,系统也不大,三四十张表,但是性能相当地下,经常down机。

  最终发现,失败不是开源框架和数据库以及应用服务器和硬件配置的错,根源在于拙劣的设计导致。

源文:   

http://qwzhl100.blog.163.com/blog/static/2133124201042694155397/
http://www.diybl.com/course/3_program/java/javaxl/200862/126932.html

分享到:
评论

相关推荐

    facade:Facade的实现——软件设计模式

    Facade(外观)模式是一种结构型设计模式,它提供了一个统一的接口,用来访问子系统中的一组接口。Facade模式使得客户端与复杂的子系统之间交互变得简单,客户端只需要与Facade交互,而无需了解子系统内部的复杂性。...

    facade设计模式

    ### Facade设计模式详解 #### 一、简介 在软件工程领域,设计模式是一种被广泛认可的解决特定问题的方法论。其中,`Facade设计模式`(外观模式)是一种结构型设计模式,它通过提供一个统一的接口来隐藏系统的复杂...

    设计模式之外观模式 facade

    外观模式(Facade Pattern)是设计模式中的一种结构型模式,主要目的是为了解决复杂的系统接口问题,提供一个简单的统一入口,使得客户端可以更方便地使用系统。在Java中,外观模式通常用来隐藏系统的复杂性,对外只...

    Command和Facade设计模式

    在软件设计模式的世界里,`Command`(命令)和`Facade`(外观)模式是非常重要的两种设计模式。它们分别服务于不同的目的,但都是为了提高代码的可读性、可维护性和灵活性。 `Command`模式是一种行为设计模式,它将...

    设计模式1,FACADE模式,Adapter

    设计模式是软件开发中的重要概念,它是一种在特定场景下解决问题的通用、可重用的设计方案。设计模式的目的是为了提高代码的可读性、可维护性以及系统设计的灵活性。本文将深入探讨FACADE模式、Adapter模式以及...

    设计模式之Facade

    eclipse工程文件 包含代码 有助理解 门面(Facade)模式 <br>外部与一个子系统的通信必须通过一个统一的门面(Facade)对象进行,这就是门面模式。 <br>医院的例子 <br>用一个例子进行说明,如果把医院...

    用三层架构与设计模式思想部署企业级数据库业务系统开发.doc

    - **界面外观层(UI Facade)**:处理用户界面的显示逻辑,负责用户交互的外观。 - **界面规则层(UI Logic)**:根据业务逻辑层的接口要求,封装用户数据,进行数据验证。 - **业务接口层(Business Interface)...

    设计模式之门面模式(Facade模式)

    设计模式之门面模式(Facade模式),介绍门面模式,实际例子分析,代码讲解等

    session facade:基于在线式银行的应用

    Session Facade是一种设计模式,常用于企业级Java应用程序,特别是在EJB(Enterprise JavaBeans)环境中,目的是解决上述问题,提高系统性能、可维护性和可扩展性。在基于在线式银行的应用中,Session Facade扮演着...

    C++ Facade模式

    1. **增加间接层**:引入Facade会增加一层间接性,可能会略微增加系统的复杂性。 2. **灵活性受限**:如果需要添加新的子系统功能,可能需要修改Facade,这违反了开闭原则。 总之,C++中的Facade模式是一种非常实用...

    FACADE模式

    **外观(Facade)模式**是一种结构型设计模式,它的主要目的是提供一个统一的接口,用于客户端访问复杂的子系统。在大型软件系统中,通常由多个模块或子系统组成,每个子系统都有自己的功能,而客户端可能需要与这些...

    三层架构与设计模式思想.pdf

    - **界面外观层(UI Facade)**:处理界面的布局和样式,与用户交互的入口。 - **界面规则层(UI Rules)**:负责用户输入的验证和格式转换。 - **业务接口层(Business Interface)**:作为业务逻辑层对外的接口,...

    迪米特法则---门面Facade模式.docx

    门面(Facade)模式是一种设计模式,遵循迪米特法则,旨在简化子系统的使用,减少客户端与子系统之间的复杂依赖关系。迪米特法则主张一个对象应该尽量减少与其他对象的交互,只与直接的朋友交流,以此提高系统的内聚...

    三层DLL.MIDAS完整源码

    - **外观服务层**(Facade Service Layer):对外提供简洁、统一的接口,隐藏内部复杂的业务逻辑。客户端通常直接与这一层交互。 - **主业务服务层**(Main Business Service Layer):负责具体的业务操作,如用户...

    PetShop架构设计(三层结构)

    【PetShop架构设计(三层结构)】 PetShop是一款经典的示例应用,它的设计模式和架构在IT界广为流传,特别是在.NET技术栈中。这个应用最初是为了对比.NET和J2EE平台的性能而诞生,随着时间的推移,PetShop发展到了4.0...

    Facade模式

    **外观(Facade)模式**是软件工程中一种常用的设计模式,属于结构型模式。它提供了一个统一的接口,用于访问子系统中的一组接口。Facade模式使得子系统更易于使用,降低了客户端与复杂子系统之间的耦合度。在Java...

    设计模式之外观模式(Facade Pattern)

    **外观模式(Facade Pattern)**是一种结构型设计模式,它主要解决的是复杂系统或子系统对外暴露一个简单统一的接口,使得客户端无需关心内部复杂的交互细节。这种模式在实际开发中广泛应用,尤其在大型项目中,它能...

Global site tag (gtag.js) - Google Analytics