Java EE 应用项目的设计分层模型

本文记录了初学者在学习JavaEE时的分层模型理解,包括领域对象层、数据访问层、业务逻辑层、控制器层和表现层。详细介绍了三层架构(表现层、业务逻辑层、数据访问层)和MVC模式,以及Facade模式的应用场景。重点讨论了如何通过这些设计模式提升系统的可维护性和可扩展性。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

        开始初学Java EE,因为需要进行前后端的维护,配合上Android的应用展示。开始新的征程。本篇文章是更偏于学习笔记,查考书籍有两本《轻量级Java EE》、《精通J2EE》。肯定会有些不严谨。目的是处于笔记和复习。

        看了《轻量级Java EE》的分层模型。大致了解普通平常的项目开发的分层设计模型。

        1.Domain Object(领域对象)层: 由系列的POJO(Plan Old Java Object,普通的、传统的java对象)组成,一般包含了自身所需要实现的业务逻辑方法;领域对象组件,领域对象抽象了系统的对象模型,一般存储在数据库里。

        2.DAO(Data Access Object,数据库访问对象)层:由系列的DAO组件组成,实现对数据库的CRUD等原子操作。 Dao组件,被称为数据访问对象。为了将业务逻辑组件的实现与DAO组件的实现分离,应为每个DAO组件提供接口,业务逻辑组件面向DAO接口编程。

       3.业务逻辑层:由业务逻辑对象组成,实现了系统所需要的业务逻辑方法。可能仅仅用于暴露Domain Object对象所实现的业务逻辑方法,或可能依赖DAO组件实现的业务逻辑方法。业务逻辑组件,是系统的核心组件,实现系统的业务逻辑。通常,一个业务逻辑方法对应一次用户操作。一个业务逻辑方法应该是一个整体的,因此要求增加事务性,但不能对数据库进行访问。

       4.控制器层:用于拦截用户请求,并调用业务逻辑组件的业务逻辑方法,处理用户请求,并根据处理结果转发到不同的表现曾组件。

       5.表现层:负责收集用户请求,并将显示处理结果。


经典基础问题:

1.什么是三层架构,是哪三层?

解析:  三层架构(3-tier application) 通常意义上的三层架构就是将整个业务应用划分为:表现层(UI)、业务逻辑层   (BLL)、数据访问层(DAL)。区分层次的目的即为了“高内聚,低耦合”的思想。

【表现层(UI):通俗讲究是展现给用户的界面,即用户在使用一个系统的时候他的所见所得

【业务逻辑层(BLL):针对具体问题的操作,也可以说是对数据层的操作,对数据业务逻辑处理。】

数据访问层(DAL):该层所做事务直接操作数据库,针对数据的增添、删除、修改、查找等。

2.理解MVC模式

解析: MVC是三个单词的缩写,分别为: 模型(Model),视图(View)和控制Controller)。 MVC模式的目的就是实现Web系统的职能分工。 Model层实现系统中的业务逻辑,通常可以用JavaBean或EJB来实现。 View层用于与用户的交互,通常用JSP来实现。 Controller层是Model与View之间沟通的桥梁,它可以分派用户的请求并选择恰当的视图以用于显示,同时它也可以解释用户的输入并将它们映射为模型层可执行的操作。

             MVC(Model View Controller)模型(model)-视图(view)-控制器(controller)

        MVC本来是存在于Deskt op程序中的,M是指数据模型,V是指用户界面,C则是控制器。使用MVC 的目的是将M和V的实现代码分离,从而使同一个程序可以使用不同的表现形式。比如一批统计数据你可以分别用柱状图、饼图来表示。C存在的目的则是确保M和V的同步,一旦M改变,V应该同步更新。

             模型-视图-控制器(MVC)是Xerox PARC在八十年代为编程语言Smalltalk-80发明的一种软件设计模式,至今已被广泛使用。最近几年被推荐为Oracle旗下Sun公司Java EE平台的设计模式,并且受到越来越多的使用 ColdFusion 和 PHP 的开发者的欢迎。模型-视图-控制器模式是一个有用的工具箱,它有很多好处,但也有一些缺点。

3.理解Facade(门面)模式

解析: Facade(外观)模式为子系统中的各类(或结构与方法)提供一个简明一致的界面,隐藏子系统的复杂性,使子系统更加容易使用。他是为子系统中的一组接口所提供的一个一致的界面。

        在遇到以下情况使用Facade模式:

      1、当你要为一个复杂子系统提供一个简单接口时。子系统往往因为不断演化而变得越来越复杂。大多数模式使用时都会产生更多更小的类。这使得子系统更具可重用性,也更容易对子系统进行定制,但这也给那些不需要定制子系统的用户带来一些使用上的困难。

          Facade可以提供一个简单的缺省视图,这一视图对大多数用户来说已经足够,而那些需要更多的可定制性的用户可以越过Facade层。

         2、客户程序与抽象类的实现部分之间存在着很大的依赖性。引入Facade将这个子系统与客户以及其他的子系统分离,可以提高子系统的独立性和可移植性。

         3、当你需要构建一个层次结构的子系统时,使用Facade模式定义子系统中每层的入口点,如果子系统之间是相互依赖的,你可以让它们仅通过Facade进行通讯,从而简化了它们之间的依赖关系。



评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值