ORM DAO MVC POJO概念

1.ORM

对象关系映射（英语：Object Relational Mapping，简称ORM，或O/RM，或O/R mapping），是一种程序技术，用于实现面向对象编程语言里不一样类型系统的数据之间的转换。从效果上说，它实际上是建立了一个可在编程语言里使用的“虚拟对象数据库”。

面向对象是从 软件工程基本原则（如耦合、聚合、封装）的基础上发展起来的，而关系数据库则是从数学理论发展而来的，两套理论存在显著的区别。为了解决这个不匹配的现象，对象关系映射技术应运而生。

对象关系映射（Object-Relational Mapping）提供了概念性的、易于理解的模型化数据的方法。ORM方法论基于三个核心原则： 简单：以最基本的形式建模数据。 传达性： 数据库结构被任何人都能理解的语言文档化。 精确性：基于数据模型建立正确标准化的结构。 典型地，建模者经过收集来自那些熟悉应用程序但不熟练的 数据建模者的人的信息开发 信息模型。建模者必须可以用非技术企业专家能够理解的术语在概念层次上与数据结构进行通信。建模者也必须能以简单的单元分析信息，对样本数据进行处理。ORM专门被设计为改进这种联系。

简单的说：ORM至关于中继数据。具体到产品上，例如ADO.NET Entity Framework。DLINQ中实体类的属性[Table]就算是一种中继数据。

 

2.DAO

DAO（数据访问对象）是一种应用程序编程接口（API），存在于微软的Visual Basic中，它容许程序员请求对微软的Access数据库的访问。DAO是微软的第一个面向对象的数据库接口。DAO对象封闭了Access的Jet函数。经过Jet函数，它还能够访问其余的结构化查询语言（SQL）数据库。

J2EE开发人员使用数据访问对象（DAO）设计模式把底层的数据访问逻辑和高层的商务逻辑分开.实现DAO模式可以更加专一于编写数据访问代码.

咱们先来回顾一下DAO设计模式和数据访问对象.

DAO基础

DAO模式是标准的J2EE设计模式之一.开发人员使用这个模式把底层的数据访问操做和上层的商务逻辑分开.一个典型的DAO实现有下列几个组件：

1. 一个DAO工厂类；

2. 一个DAO接口；

3. 一个实现DAO接口的具体类；

4. 数据传递对象（有些时候叫作值对象）.

具体的DAO类包含了从特定的数据源访问数据的逻辑。在下面的这段中你将学到设计和实现数据访问对象的技术。

事务划分：

关于DAO要记住的一件重要事情是它们是事务性对象。每一个被DAO执行的操做（对象建立，更新、或删除数据）都是和事务相关联的。一样的，事务划分（transaction demarcation）的概念是特别重要的。

事务划分是在事务界定定义中的方式。J2EE规范为事务划分描述了两种模式：编程性事务（programmatic）和声明性事务（declarative）.下表是对这两种模式的拆分：

声明性事务划分 编程性事务划分

程序员使用EJB的布署描述符声明事务属性 程序员担负编写事务逻辑代码的责任。

运行时环境（EJB容器）使用这些属性来自动的管理事务。应用程序经过一个API接口来控制事务。

 

3.MVC

MVC - 1、MVC设计思想

　　MVC英文即Model-View-Controller，即把一个应用的输入、处理、输出流程按照Model、View、Controller的方式进行分离，这样一个应用被分红三个层——模型层、视图层、控制层。 　　

视图

　　视图(View)表明用户交互界面，对于Web应用来讲，能够归纳为HTML界面，但有可能为XHTML、XML和Applet。随着应用的复杂性和规模性，界面的处理也变得具备挑战性。一个应用可能有不少不一样的视图，MVC设计模式对于视图的处理仅限于视图上数据的采集和处理，以及用户的请求，而不包括在视图上的业务流程的处理。业务流程的处理交予模型(Model)处理。好比一个订单的视图只接受来自模型的数据并显示给用户，以及将用户界面的输入数据和请求传递给控制和模型。 　　

模型

　　模型(Model)：就是业务流程/状态的处理以及业务规则的制定。业务流程的处理过程对其它层来讲是黑箱操做，模型接受视图请求的数据，并返回最终的处理结果。业务模型的设计能够说是MVC最主要的核心。目前流行的EJB模型就是一个典型的应用例子，它从应用技术实现的角度对模型作了进一步的划分，以便充分利用现有的组件，但它不能做为应用设计模型的框架。它仅仅告诉你按这种模型设计就能够利用某些技术组件，从而减小了技术上的困难。对一个开发者来讲，就能够专一于业务模型的设计。MVC设计模式告诉咱们，把应用的模型按必定的规则抽取出来，抽取的层次很重要，这也是判断开发人员是否优秀的设计依据。抽象与具体不能隔得太远，也不能太近。MVC并无提供模型的设计方法，而只告诉你应该组织管理这些模型，以便于模型的重构和提升重用性。咱们能够用对象编程来作比喻，MVC定义了一个顶级类，告诉它的子类你只能作这些，但无法限制你能作这些。这点对编程的开发人员很是重要。

　　业务模型还有一个很重要的模型那就是数据模型。数据模型主要指实体对象的数据 保存（持续化）。好比将一张订单保存到数据库，从数据库获取订单。咱们能够将这个模型单独列出，全部有关数据库的操做只限制在该模型中。

控制

　　控制(Controller)能够理解为从用户接收请求, 将模型与视图匹配在一块儿，共同完成用户的请求。划分控制层的做用也很明显，它清楚地告诉你，它就是一个分发器，选择什么样的模型，选择什么样的视图，能够完成什么样的用户请求。控制层并不作任何的数据处理。例如，用户点击一个链接，控制层接受请求后, 并不处理业务信息，它只把用户的信息传递给模型，告诉模型作什么，选择符合要求的视图返回给用户。所以，一个模型可能对应多个视图，一个视图可能对应多个模型。

模型、视图与控制器的分离，使得一个模型能够具备多个显示视图。若是用户经过某个视图的控制器改变了模型的数据，全部其它依赖于这些数据的视图都应反映到这些变化。所以，不管什么时候发生了何种数据变化，控制器都会将变化通知全部的视图，致使显示的更新。这其实是一种模型的变化-传播机制。模型、视图、控制器三者之间的关系和各自的主要功能，如图1所示。 

MVC - 2、MVC设计模式的实现

　　ASP.NET提供了一个很好的实现这种经典设计模式的相似环境。开发者经过在ASPX页面中开发用户接口来实现视图；控制器的功能在逻辑功能代码(.cs)中实现；模型一般对应应用系统的业务部分。在ASP.NET中实现这种设计而提供的一个多层系统，较经典的ASP结构实现的系统来讲有明显的优势。将用户显示（视图）从动做（控制器）中分离出来,提升了代码的重用性。将数据（模型）从对其操做的动做（控制器）分离出来可让你设计一个与后台存储数据无关的系统。就MVC结构的本质而言，它是一种解决耦合系统问题的方法。

2.1 视图

　　视图是模型的表示，它提供用户交互界面。使用多个包含单显示页面的用户部件，复杂的Web页面能够展现来自多个数据源的内容，而且网页人员，美工能独自参与这些Web页面的开发和维护。

　　在ASP.NET下，视图的实现很简单。能够像开发WINDOWS界面同样直接在集成开发环境下经过拖动控件来完成页面开发本。本文中介绍每个页面都采用复合视图的形式即：一个页面由多个子视图(用户部件)组成；子视图能够是最简单HTML 控件、服务器控件或多个控件嵌套构而成的Web自定义控件。页面都由模板定义，模板定义了页面的布局，用户部件的标签和数目，用户指定一个模板，平台根据这些信息自动建立页面。针对静态的模板内容，如页面上的站点导航，菜单，友好连接，这些使用缺省的模板内容配置；针对动态的模板内容(主要是业务内容)，因为用户的请求不一样，只能使用后期绑定，而且针对用户的不一样，用户部件的显示内容进行过滤。使用由用户部件根据模板配置组成的组合页面，它加强了可重用性，并原型化了站点的布局。

　　视图部分大体处理流程以下：首先，页面模板定义了页面的布局；页面配置文件定义视图标签的具体内容（用户部件）；而后，由页面布局策略类初始化并加载页面；每一个用户部件根据它本身的配置进行初始化，加载校验器并设置参数，以及事件的委托等；用户提交后，经过了表示层的校验，用户部件把数据自动提交给业务实体即模型。

　　这一部分主要定义了WEB页面基类PageBase；页面布局策略类PageLayout，完成页面布局，用于加载用户部件到页面；用户部件基类UserControlBase即用户部件框架，用于动态加载检验部件，以及实现用户部件的个性化。为了实现WEB应用的灵活性，视图部分也用到了许多配置文件例如：置文件有模板配置、页面配置、路径配置、验证配置等。

2.2 控制器

　　为了可以控制和协调每一个用户跨越多个请求的处理，控制机制应该以集中的方式进行管理。所以，为了达到集中管理的目的引入了控制器。应用程序的控制器集中从客户端接收请求（典型状况下是一个运行浏览器的用户），决定执行什么商业逻辑功能，而后将产生下一步用户界面的责任委派给一个适当的视图组件。

　　用控制器提供一个控制和处理请求的集中入口点，它负责接收、截取并处理用户请求；并将请求委托给分发者类，根据当前状态和业务操做的结果决定向客户呈现的视图。在这一部分主要定义了HttpReqDispatcher(分发者类)、HttpCapture(请求捕获者类)、Controller(控制器类)等，它们相互配合来完成控制器的功能。请求捕获者类捕获HTTP请求并转发给控制器类。控制器类是系统中处理全部请求的最初入口点。控制器完成一些必要的处理后把请求委托给分发者类；分发者类分发者负责视图的管理和导航，它管理将选择哪一个视图提供给用户，并提供给分发资源控制。在这一部分分别采用了分发者、策略、工厂方法、适配器等设计模式。

　　为了使请求捕获者类自动捕获用户请求并进行处理，ASP.NET 提供低级别的请求/响应 API，使开发人员可以使用 .NET 框架类为传入的 HTTP 请求提供服务。为此，必须创做支持 System.Web.IHTTPHandler 接口和实现 ProcessRequest() 方法的类即：请求捕获者类，并在web.config 的 ＜httphandlers＞ 节中添加类。ASP.NET 收到的每一个传入 HTTP 请求最终由实现 IHTTPHandler 的类的特定实例来处理。IHttpHandlerFactory 提供了处理 IHttpHandler 实例 URL 请求的实际解析的结构。HTTP 处理程序和工厂在 ASP.NET 配置中声明为 web.config 文件的一部分。ASP.NET 定义了一个 ＜httphandlers＞ 配置节，在其中能够添加和移除处理程序和工厂。子目录继承 HttpHandlerFactory 和 HttpHandler 的设置。 HTTP 处理程序和工厂是 ASP.NET 页框架的主体。工厂将每一个请求分配给一个处理程序，后者处理该请求。 例如，在全局 machine.config 文件中，ASP.NET 将全部对 ASPx 文件的请求映射到 HttpCapture类：

＜httphandlers＞
...
...
＜/httphandlers＞

2.3 模型

　　MVC系统中的模型从概念上能够分为两类――系统的内部状态和改变系统状态的动做。模型是你全部的商业逻辑代码片断所在。本文为模型提供了业务实体对象和业务处理对象：全部的业务处理对象都是从ProcessBase类派生的子类。业务处理对象封装了具体的处理逻辑，调用业务逻辑模型，而且把响应提交到合适的视图组件以产生响应。业务实体对象能够经过定义属性描述客户端表单数据。全部业务实体对象都EntityBase派生子类对象，业务处理对象能够直接对它进行读写，而再也不须要和request、response对象进行数据交互。经过业务实体对象实现了对视图和模型之间交互的支持。实现时把"作什么"（业务处理）和"如何作"（业务实体）分离。这样能够实现业务逻辑的重用。因为各个应用的具体业务是不一样的，这里再也不列举其具体代码实例。

 

4.POJO

POJO(Plain Ordinary Java Object)简单的Java对象，实际就是普通JavaBeans，是为了不和EJB混淆所创造的简称。

使用POJO名称是为了不和EJB混淆起来, 并且简称比较直接. 其中有一些属性及其getter setter方法的类,没有业务逻辑，有时能够做为VO(value -object)或dto(Data Transform Object)来使用.固然,若是你有一个简单的运算属性也是能够的,但不容许有业务方法,也不能携带有connection之类的方法。