数据访问层

http://www.cnblogs.com/seaky/archive/2011/04/06/1982533.html 在深入分析MVC和MVP之前，我们有必要回顾下经典的三层架构。分层是计算机学科解决许多问题的法宝。在企业应用和互联网应用中，分层架构得到了非常广泛的应用。3层架构是各种层架构的基础，3层架构简单描述如下: 展示层 :展示层有两个职责 1负责展示业务数据 2提供用户输入的接口 业务逻辑层 :业务逻辑层的职责是接受展示层的输入，并经过业务处理逻辑，返回业务数据。 数据访问层 :数据访问层提供系统数据的存取服务。 从架构到实现是存在一些"距离"的，架构的实现是要基于应用场景，实现方案也有所不一样。 本文考虑两种应用场景来讨论MVC和MVP: 第一是c/s架构，也就是所谓的胖客户端，像RIA属于这类。Flex，ajax等技术都可以归结到RIA，手机APP，winform连接到远程服务的应用都可以归结这一类。 第二是b/s架构(某些web程序部分的利用了ajax，排除利用ajax的这部分)，也就是瘦客户端，b是指浏览器，在b/s架构中http协议是客户端和服务端通信的唯一协议，而且是通过浏览器来展示数据的。 基于层的架构的实现中的一个问题就是层与层之间如何通信，以及如何在层间传递数据。 首先看看数据访问层和业务层之间的通信和数据传递。 (注意， 数据访问层不保存持久数据

上一篇 打造自己的数据访问层（一） 中，我们已了解了.NET对数据库操作的基本原理，并就Ado.net对象的使用提出了几点疑问： 1、如何由系统来判断数据库型。 2、如何消除这些重复代码。 而上篇中也提出了一种解决思路，对ADO.NET对象进行封装，具体应该如何实施？ 1、需要一个对象，该对象用于建立内存表与物理表的之间映射关系，解决数据查询、更新操作，形成了数据映射对象，定义为DataMapping。 2、每一个映射对象只与一张物理建立映射关系，如果有多个这样的对象同时操作，如何解决？这时就需要另一个对象，用于添加映射对象集合，打包映射对象操作，形成了数据执行者，定义为DataExecutor。 想想看，只需要这两个基本对象，就可以形成简单的数据访问层了。 先实现DataMapping，它应具备如下功能。 1、需要知道物理表的信息，表名、主键集、字段集。 2、需要知道映射的是什么类型的数据库，MSSql数据库、Oracle数据库、MySql数据库或者其他类型的数据库。 3、可查询数据，即填充内存表。 4、可更新数据，并且可设置更新操作方式。 5、可加入到事务中去。 根据上述功能，可初步设计出的DataMapping类: public class DataMapping{ public DataMapping() { } /// <summary> /// 填充数据集 /// <

前言 记得几个月前，在一次北京博客园俱乐部的活动上，最后一个环节是话题自由讨论。就是提几个话题，然后大家各自加入感兴趣的话题小组，进行自由讨论。当时金色海洋同学提出了一个话题——“什么是业务逻辑”。当时我和大家讨论ASP.NET MVC的相关话题去了，就没能加入“业务逻辑”组的讨论，比较遗憾。 其实，一段时间内，我脑子里对“业务逻辑”的概念也是非常模糊的。但在不断地阅读、思考和实践过程中，这个概念及其相关的内容才在我脑子里渐渐清晰。我想，很多朋友也许也对这个概念不是很了解，所以愿意结合既有资料和自己的思考，总结一篇关于业务逻辑的概述性文章，一则与朋友们分享探讨，二则也是为自己对业务逻辑的学习做一个总结和提升。因为我还不敢说对业务逻辑内涵及外延理解的非常充分，所以文中如有不当之处，还请各位不用客气，尽管批评就好！ 内容提要 =================== 前篇===================== 前言 内容提要 1、我把业务逻辑丢了！——找回丢失的业务逻辑 2、细说业务逻辑 2.1、业务逻辑到底是什么 2.2、业务逻辑的组成结构 2.2.1、领域实体（Domain Entity） 2.2.2、业务规则（Business Rules） 2.2.3、完整性约束（Validation） 2.2.4、业务流程及工作流（Business Processes and

原文链接： http://kb.cnblogs.com/page/145705/ 通过前面两篇，我想各位朋友对“面向接口编程”的思想有了一定认识，并通过第二篇的例子，获得了一定的直观印象。但是，第二篇中的例子旨在展示面向接口编程的实现方法，比较简单，不能体现出面向接口编程的优势和这种思想的内涵。那么，这一篇作为本系列的终结篇，将通过分析几个比较有深度的模式或架构，解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。 　　这篇的内容可能会比较抽象，望谅解。 　　 1. 从MVC开始 　　MVC简介： 　　本文不打算详细解释MVC架构，而是把重点放在其中的面向接口思想上。所以在这里，只对MVC做一个简略的介绍。 　　MVC是一种用于表示层设计的复合设计模式。M、V、C分别表示模型（Model）、View（视图）、Controller（控制器）。它们的职责如下： 　　模型：用于存储应用中的数据及运行逻辑，是应用的实体。 　　视图：负责可视部分，用于与用户交互及呈现数据。视图只负责显示，不负责将用户的操作行为解释给模型。 　　控制器：负责将用户的行为解释给模型。根据指定的策略和用户的操作，调用模型的逻辑。 　　关于三者的关系，我画了一张图，大家请看： 　　 MVC模式示意 　　它们之间的交互有以下几种： 　　1. 当用户在视图上做任何需要调用模型的操作时

注意：本文所介绍的框架已有新版本， 点击后面链接即可阅读。 【ClownFish：比手写代码还快的通用数据访问层】 今天来晒晒我的通用数据访问层。 写了很多年的数据库项目，数据访问嘛，一直是用业务实体+存储过程的方式，因此经常会写很多调用存储过程的代码。这些代码用Ado.net如何写，我想大家应该都知道： 创建Connection, 创建Command, 给命令参数一个一个赋值，然后调用，调用完成后，如果有输出参数，则要读出来，如果有结果集，则要将结果集转换成自己的实体列表，这个过程也是非常机械化的。 总之，调用任何存储过程都需要这样一堆类似的代码。 我是个喜欢最求完美的人，自然不喜欢每个项目都有这样一堆机械代码的存在，于是经过不断的重构代码，慢慢的就形成了自己的通用数据访问层。 我的通用数据访问层具有以下特点： 1. 可用于访问各种类型的数据库，让您的应用程序从特定的数据库类型中解藕出来，从而非常简单地就可以实现对多种数据库的支持。 2. 非常方便的调用存储过程、将数据库的结果转成实体类型（或列表）、调用完成后自动“回写”输出参数到实体对象。 只需要一个调用便可实现这三个操作步骤。 3. 数据访问层可以同时支持多种数据库类型的多个连接。并可以在运行时简单的切换。 4. 数据访问层可以非常方便地实现类似“多帐套数据库”的支持，即根据不同的客户端请求来切换相应的数据库连接。 5.

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 第三天我们将学习Asp.Net中数据处理功能，了解数据访问层，EF，以及EF中常用的代码实现方式，创建数据访问层和数据入口，处理Post数据，以及数据验证等功能。 系列文章 七天学会ASP.NET MVC (一)——深入理解ASP.NET MVC 七天学会ASP.NET MVC (二)——ASP.NET MVC 数据传递 七天学会ASP.NET MVC (三)——ASP.Net MVC 数据处理 目录： 数据访问层 实体框架（EF）简述 什么是代码优先的方法？ 实验8——在项目中添加数据访问层 关于实验8 实验9——创建数据输入屏幕 实验10——获取服务端或控制器端传递的数据。 实验11——重置及取消按钮 实验12——保存数据。库记录并更新表格 实验13——添加服务器端验证 实验14——自定义服务器端验证 结论 数据访问层 在实际开发中，如果一个项目不包含任何数据库，那么这个项目是不完整的，我们在一二节实例中未涉及数据库，在本节开始，实验8中讲解一个关于数据库和数据库层的实例。 本节将使用SQL Server和EF（Entity Framework）创建相关的数据库及数据库访问层。 简述实体框架（EF） EF是一种ORM工具，ORM表示对象关联映射。 在RDMS中，对象称为表格和列对象，而在.net中（面向对象

【推荐】2019 Java 开发者跳槽指南.pdf(吐血整理) >>> 一、开篇 距离上篇《 Step by Step-构建自己的ORM系列-开篇 》的时间间隔的太久了，很对不住大家啊，主要是因为有几个系列必须提前先写完，才能继续这个系列，当然我也在 写这几个系列的过程中，对ORM这个系列中的原来的实现的想法有了新的认识和改进，当然这些都不是说是很先进的思想或者认识，也可能是大家见过的思路吧,希望后面我能在 写设计模式系列的过程中，穿插讲解ORM系列，当然我的这个构建的系列，也只能说是很简易的，自己平时开发个小应用工具或者什么的，可能用他，因为是自己开发的嘛，毕竟 使用起来还是比较顺手的！符合自己的操作习惯嘛。 当然我写这个系列的过程中，也会有自己认识偏激的地方，或者思路不正确的地方，还请大伙多多指出和批评。我也是在我目前的项目中学习到了很多的宝贵的经验，其实 我们应该能看到ORM给我们提供的方便和不便之处，我们取其精华，剔除糟粕，不过这真的很难。我其实对一些流行的ORM的底层实现，研究的不多也不深，像Nhibernate，我 只是了解Hibernate，是当时从JAVA中了解过来的，不深入，Castle框架倒是用过一段时间，EntityFreamWork，我也没有用过，只是象征性的下载最新版本，体验了下AOP的 方式，我感觉其实有很多的时候，我们使用AOP的方式

通过前面两篇，我想各位朋友对“面向接口编程”的思想有了一定认识，并通过第二篇的例子，获得了一定的直观印象。但是，第二篇中的例子旨在展示面向接口编程的实现方法，比较简单，不能体现出面向接口编程的优势和这种思想的内涵。那么，这一篇作为本系列的终结篇，将通过分析几个比较有深度的模式或架构，解析隐藏其背后的面向接口思想。这篇我将要分析的分别是MVC模式和.NET平台的分层架构。 这篇的内容可能会比较抽象，望谅解。 1.从MVC开始 MVC简介： 本文不打算详细解释MVC架构，而是把重点放在其中的面向接口思想上。所以在这里，只对MVC做一个简略的介绍。 MVC是一种用于表示层设计的复合设计模式。M、V、C分别表示模型（Model）、View（视图）、Controller（控制器）。它们的职责如下： 模型：用于存储应用中的数据及运行逻辑，是应用的实体。 视图：负责可视部分，用于与用户交互及呈现数据。视图只负责显示，不负责将用户的操作行为解释给模型。 控制器：负责将用户的行为解释给模型。根据指定的策略和用户的操作，调用模型的逻辑。 关于三者的关系，我画了一张图，大家请看： 图3.1 MVC模式示意 它们之间的交互有以下几种： 1.当用户在视图上做任何需要调用模型的操作时，它的请求将被控制器 截获。 2.控制器按照自身指定的策略，将用户行为翻译成模型操作，调用模型相应逻辑实现。 3

在前面简单描述了下 服务层 ， SOA面向服务架构 ， 架构设计-业务逻辑层 ，以及一些 面向设计原则理解 和 软件架构设计箴言 。这篇博客我们将继续进入我们的下一层：数据访问层。无论你用的是什么开发模式或者是业务模式，到最后最必须具有持久化机制，持久化到持久化介质，并能对数据进行读取和写入CRUD。这就是数据访问层。你可能是利用xml等文件格式磁盘存储，常用的关系数据库存储，或者NoSql(not only sql)的内存存储或文档存储等等存储介质。而这里我只关心关系数据库存储。 数据层需要提供的职责有： 1：CRUD服务。作为唯一可以与存储介质交互的中间层出现，负责业务对象的增加，修改，删除，加载。 2：查询服务。这不同于CRUD中的R（read），read倾向于的单个对象，元组。而这里的查询针对复杂查询，比如一个国内电商的客户为四川的订单。这里会涉及仓储层。所谓仓储模式指的是一个提供业务对象查询的类，他隐藏了数据查询的解析步骤，封装sql解析逻辑。 3：事务管理。这里所说的是业务事务，在一个应用系统中每次请求都会产生多次的多数据对象的新增，修改，删除操作。如果我们每次都依次代开数据库连接，准备数据包，操作数据库，关闭数据连接。这些将会给我们带来很多不必要的性能开销。数据库管理员经常会要求“尽量少的与数据库交互”，这也必须成为我们的开发原则

三层架构 ： 通常意义上的三层架构就是将整个业务应用划分为：界面层（User Interface layer）、业务逻辑层（Business Logic Layer）、数据访问层（Data access layer）。区分层次的目的即为了“ 高内聚低耦合 ”的思想。在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。微软推荐的分层式结构一般分为三层，从下至上分别为：数据访问层、业务逻辑层（又或称为领域层）、表示层。 顾名思义，三层架构分为三层，分别是“数据访问层”、“业务逻辑层”、“表示层”。 数据访问层：数据访问层在作业过程中访问数据系统中的文件，实现对数据库中数据的读取保存操作。 表示层：主要功能是显示数据和接受传输用户的数据，可以在为网站的系统运行提供交互式操作界面，表示层的应用方式比较常见，例如Windows窗体和Web页面。 业务逻辑层：将用户的输入信息进行甄别处理，分别保存。建立新的数据存储方式，在存储过程中对数据进行读取，将“商业逻辑”描述代码进行包含。 三层架构软件系统为用户的数据传输、提取、储存创造了便利条件。在应用数据时，信息划分架构开发项目，对各层次之间的工作职责进行清晰规划，这样就降低了网站系统的维护风险。 原理： 3个层次中，系统主要功能和业务逻辑都在业务逻辑层进行处理。 所谓三层体系结构，是在客户端与数据库之间加入了一个“中间层”，也叫组件层