基于.NET平台的分层架构实战(七)—数据访问层的第一种实现:Access+SQL

经过上面篇文章的介绍,整个系统的框架算是基本搭建完了,下面,我们要具体实现各个层次。关于数据访问层的实现,我准备讨论三种实 现方式,这一篇文章讨论第一种:Access+动态生成SQL。

顾名思义,这种实现将使用Access作为后台数据库,而操作方式也是最基本的 使用SQL命令。

在具体编写实现代码之前,我们需要做一些准备工作:

第一步,我们要将Access数据库搭建完成,具体做法如下 。

在Web工程下新建一个文件夹,命名为AccessData,并在其中新建一个mdb文件(即Access数据库文件),按照前面介绍过的数据库设计构架,将数据表及表间关系建好,这里不再赘述。

第二步,我们要进行一些配置。

打开Web工程下的Web.config文件,在其中 的appSettings节点下,添加如下键值:

   <add key="AccessConnectionString" value="Provider=Microsoft.Jet.OLEDB.4.0;Data Source={DBPath}"/>
   <add key="AccessPath" value="~/AccessData/AccessDatabase.mdb"/>

第一条为Access的连接字符串,第二条为Access数据库文件的路 径,其中“~”表示网站根目录。

第三步,新建一个工程。

我们要新建一个工程AccessDAL,用来存放Access数据访 问层的代码。

准备工作做完了,现在来实现具体的代码。

1.编写数据访问助手类

因为很多数据访问操作流程很相似,所 以,这里将一些可复用的代码抽取出来,编写成助手类,以此减少代码量,提高代码复用性。

这个助手类放在AccessDAL下,叫 AccessDALHelper,主要负责Access数据库的访问。它包括三个方法:

GetConnectionString:从配置文件中读取配置项,组合成连接字 符串。

ExecuteSQLNonQuery:执行指定SQL语句,不返回任何值,一般用于Insert,Delete,Update命令。

ExecuteSQLDataReader:执行SQL语句返回查询结果,一般用于Select命令。

时间: 2024-10-01 16:16:14

基于.NET平台的分层架构实战(七)—数据访问层的第一种实现:Access+SQL的相关文章

基于.NET平台的分层架构实战(一)—综述

通过浏览博客园的文章发现,很多朋友对分层架构特别感兴趣,刚好我刚做完 的毕业设计就是专门研究.NET平台上分层架构的(题目叫"基于.NET平台的 分层架构与设计模式应用研究").通过做这篇论文,我对分层架构有了一 定的了解,所以,就萌发了想写一个文章系列,详述一下分层架构.然而,论文 的理论性太强,不适合在网上发布,尤其不适合初学者理解,所以,我想在这个 文章系列中,少讲理论,而是通过做一个完整的案例来讨论分层架构的基本方法 ,这样会直观很多.希望在这个文章系列的写作过程中,能和朋友们

基于.NET平台的分层架构实战(七-外一篇)—对数据访问层第一种实现(Access+

基于.NET平台的分层架构实战(七-外一篇)-对数据访问层第一种实现(Access+SQL)的重构 昨天的文章基于.NET平台的分层架构实战(七)--数据访问层的第一种实现:Access+SQL发布后,很多朋友对我的程序提出了意见和建议,在这里先谢谢你们!!!尤其是金色海洋(jyk),对我的程序提出了很多建设性的意见. 我大体总结了一下,昨天程序的主要缺点有: 1.Connection对象没有关闭 2.DataReader对象没有关闭 3.相似代码太多,造成代码冗余. 其中第一点问题,目前还没有

基于.NET平台的分层架构实战

基于.NET平台的分层架构实战(十一)-表示层的实现 基于.NET平台的分层架构实战(十)-业务逻辑层的实现 基于.NET平台的分层架构实战(九)-数据访问层的第三种实现:基 基于.NET平台的分层架构实战(八)-数据访问层的第二种实现:SQ 基于.NET平台的分层架构实战(七-外一篇)-对数据访问层第一种 基于.NET平台的分层架构实战(七)-数据访问层的第一种实现:Acc 基于.NET平台的分层架构实战(六)-依赖注入机制及IoC的设计 基于.NET平台的分层架构实战(五)-接口的设计与实现

基于.NET平台的分层架构实战(九)—数据访问层的第三种实现:基于NBear框架

基于.NET平台的分层架构实战(九)-数据访问层的第三种实现:基于NBear框架的ORM实现 前面的文章讨论了使用SQL语句和存储过程两种数据访问层的实现方式,这一篇里,将讨论使用ORM方式实现数据访问层的方法. 对象-关系映射(Object/Relation Mapping,简称ORM),是随着面向对象的软件开发方法发展而产生的.面向对象的开发方法是当今企业级应用开发环境中的主流开发方法,关系数据库是企业级应用环境中永久存放数据的主流数据存储系统.对象和关系数据是业务实体的两种表现形式,业务实

基于.NET平台的分层架构实战(八)—数据访问层的第二种实现:SQLServer+存储

基于.NET平台的分层架构实战(八)-数据访问层的第二种实现:SQLServer+存储过程 在上一篇中,讨论了使用SQL构建数据访问层的方法,并且针对的是Access数据库.而这一篇中,将要创建一个针对SQLServer数据库的数据访问层,并且配合存储过程实现. 曾经有朋友问我使用SQL和存储过程在效率上的差别,惭愧的是我对这方面没有研究,也没有实际做过测试.通过查阅资料,发现在一般情况下,存储过程的效率由于使用SQL,但是也不绝对,也发现有的朋友测试时发现在特定情况下SQL的效率优于存储过程,

基于.NET平台的分层架构实战(五)—接口的设计与实现

接下来,将进行接口的设计.这里包括数据访问层接口和业务逻辑层接口.在 分层架构中,接口扮演着非常重要的角色,它不但直接决定了各层中的各个操作 类需要实现何种操作,而且它明确了各个层次的职责.接口也是系统实现依赖注 入机制不可缺少的部分. 本项目的接口设计将按如下顺序进行: 1.首先由前文的需求分析,列出主要的UI部分. 2.分析各个UI需 要什么业务逻辑支持,从而确定业务逻辑层接口. 3.分析业务逻辑层接口 需要何种数据访问操作,从而确定数据访问层接口. 另外,为保证完全的 面向对象特性,接口之

基于.NET平台的分层架构实战(六)—依赖注入机制及IoC的设计

我们设计的分层架构,层与层之间应该是松散耦合的.因为是单向单一调用, 所以,这里的"松散耦合"实际是指上层类不能具体依赖于下层类, 而应该依赖于下层提供的一个接口.这样,上层类不能直接实例化下层中的类, 而只持有接口,至于接口所指变量最终究竟是哪一个类,则由依赖注入机制决定 . 之所以这样做,是为了实现层与层之间的"可替换"式设计 ,例如,现在需要换一种方式实现数据访问层,只要这个实现遵循了前面定义的 数据访问层接口,业务逻辑层和表示层不需要做任何改动,只需要改一下

基于.NET平台的分层架构实战(十)—业务逻辑层的实现

在这一篇文章中,将实现一个NGuestBook的业务逻辑层. 在实际应用 中,业务逻辑层是至关重要的,他承载着整个系统最核心的部分,也是客户最关 注的部分.这一部分的实现,通常需要技术专家和领域专家通力合作.当然,在 本文章系列的Demo中,由于业务逻辑的简单性,这里看的可能还不是很明显. 在本篇文章的业务逻辑层实现中,业务逻辑层主要承担了以下职责: 1.对不同数据访问层的封装.使得表示层可以不关心具体的数据访问层. 2.业务逻辑数据的填充与转换.如管理员口令的加密. 3.核心业 务的实现.这里

基于.NET平台的分层架构实战(四)—实体类的设计与实现

实体类是现实实体在计算机中的表示.它贯穿于整个架构,负担着在各层次及 模块间传递数据的职责.一般来说,实体类可以分为"贫血实体类" 和"充血实体类",前者仅仅保存实体的属性,而后者还包含一些实 体间的关系与逻辑.我们在这个Demo中用的实体类将是"贫血实体类 ". 大多情况下,实体类和数据库中的表(这里指实体表,不包括 表示多对多对应的关系表)是一一对应的,但这并不是一个限制,在复杂的数据 库设计中,有可能出现一个实体类对应多个表,或者交叉对应的