如何编写带有ORM的三层架构，最好给个例子看看。

Posted 2023-04-25

.net的ORM三层架构

ORM可以这么理解：
一般的，我们把系统所需要的数据放在数据库中。而显示给用户的页面中使用的数据是通过读取数据库并进一步处理得到的。
而数据库中的数据是结构的。
我们需要的.net编程中的数据时面向对象整合了的。
故：我们需要一种机制，可以把数据库中的结构性的数据转换为面向对象的数据。于是就出现了系统架构中常见的3层架构：

底层：DAL（Data Access Layer，数据访问层）
中间：BLL (Bussiness Logic Layer，业务逻辑层）
顶层：UI层~

DAL中，我们使用实体类完成对数据库表的封装：
例如：我们构建一个文章管理系统。需要以下表
[Articles] [Categories] [Comments]
以[Articles]为例，包含的字段：
[ArticleID] [Title] [Content] [AddedBy] [AddedDate]
DAL层对应的实体类为[ArticleDetails]
包含以下属性[ArticleID] [Title].......等5个属性，以此对应表的5个字段。

对应DB中的3个表，我们有3个实体类。
创建类SqlArticlesProvider 来完成对DB的操作的封装。
通常每个方法封装一个存储过程~
例如：GetArticles(int categoryID)方法中。
我们连接DB，调用SP，并将返回的DataReader封装到实体类集合List<ArticleDetails>中。以用于传输给BLL层。

BLL层：
之中的类称为域对象。有[Article] [Category] [Comment]
这里的每个类就是我们传统OOP中的类。
每个对象包含描述自己的属性和可执行行为的方法。

UI层，直接调用BLL层的类以获取数据，并通过数据绑定控件显示的页面等~

说的有点乱。。。光这么着说确实不是特别充分。。
而且真正实践编程起来，比这个复杂。。
三层架构之后的系统更易于维护。变更底层数据存储，需要改动的地方非常少。
故，主要是用于大中型系统架构。

而且现在推出LINQ后，对编码量也降低了。但是单独学习LINQ，时间也不会少。
如果不要LINQ的话，还是有很多工具代码可以帮助自动的构建一些类的~追问

应为我是写网站的从来没有用过ORM映射（直接DAL读了数据存在Model里），很想学习一下，从前辈那你看到了用ORM映射写的数据访问层代码简洁高效，能不能给段代码例子，或者推荐一本书，最好是有个这样的架构例子，以起到抛砖引玉的作用！小弟拜托了！

追答

《ASP.NET2.0网站开发全程解析》
我最开始了解到ORM的三层架构是从这本书上看到的。
这本书本身写的相当精彩~我个人认为每个用.NET自己开发网站的人都应该看看~里面把建站应用到的技术讲的很全面~开发的模块也很多~会员系统/新闻系统/论坛系统/电子商城等等吧~最后构成了一个完全可用的全功能网站~

另外~像ORM这种东西就属于设计模式范畴了~你要是单纯的想了解它，可以找本设计模式的书来看~《大话设计模式》就很不错~是设计模式里面最幽默最易懂的书了~不过代码语言示例选择的是C#~

至于源代码啊~你随便去网上下个应用程序就应该是了~贴源代码有点累。。我用一个应用程序的app_code文件夹的结构给你简单说下吧~
+app_code
+DAL
ArticleDetails ==DAL实体类（封装文章表字段）
CommentDetails ==实体类（封装评论表字段
ArticleProvider ==DAL文章系统的提供程序（抽象类，定义方法接口，封装存储过程）
SqlArticleProvider ==继承自ArticleProvider，实现具体的代码。可在web.config中设置
+BLL
Article==BLL域对象，是传统编程OOP中的对象。代表文章对象。
Comment==域对象。数据从DAL的Provider获取

恩。。基本上是这样，在实现上还会有一些辅助类~就上面的两本书，没事买来看看吧~我.NET也是自学的~
刚开始小有成就的时候，想自己做个网站，做到一半，突然发现《网站开发全程解析》这本书。。。看了前三章。。就把自己的网站全部推翻来重新做了。。。

最后。.NET在数据处理方面，有LINQ。大大减少了编程代码。上两本书都没有写到。是.NET3.5的时候出了。我觉得《LINQ实战》这本书写的就不错~

以上~

参考技术A ORM应该指的是一种设计思想。推荐看微软官方推荐的petshop。当然petshop里头不仅仅有ORM设计，还有很多其他的设计思路。看起来会吃力一些，但是可以学的东西也多。 参考技术B ORM 是一种技术（实现），和架构无关，比如LINQ TO SQL 是一种ORM 技术，你可以用在任何架构中。
当然一般在3层架构中ORM是作为数据层的一部分出现的。
LINQ TO SQL 的例子到处都是。
3层架构你可以参考CSLA.

http://msdn.microsoft.com/zh-CN/practices/

三层架构分析

三层一般分为两类：物理上的三层和逻辑上的三层架构；物理三层架构是以逻辑的三层架构为基础的，假设没有了逻辑的三层。就根本谈不上物理三层架构的部署。

    什么是物理三层架构呢？

    从简单了说就是每一层都分别做成一个组件。如业务逻辑组件，业务实体组件，数据訪问组件等。在到复杂一些就是构建分布式系统，比如将业务逻辑层与数据訪问分别部署在不同的server上。

我们这里讲的主要是逻辑上的三层架构。

三层基础知识

在软件体系架构设计中，分层式结构是最常见，也是最重要的一种结构。

微软推荐的分层式结构一般分为三层，从下至上分别为：数据訪问层、业务逻辑层（又或称为领域层）、表示层。

那么每层都有什么作用呢。见下表：

	作用	设计原则	经常使用技术
表示层(UI)	向用户展现特定业务数据，採集用户的输入信息和操作	用户至上。兼顾简洁；不包括不论什么业务相关的逻辑处理	WindowsＦｏｒｍ＼ＡＳＰ.ＮＥＴ
业务逻辑层(BLL)	从ＤＡＬ中获取数据，在ＵＩ显示；从ＵＩ中获取用户指令和数据。运行业务逻辑或通过ＤＡＬ写入数据源。	作为U层与Ｄ层的桥梁，仅仅负责数据处理传递，不涉及ＳＱＬ语句和ＡＤＯ.ＮＥＴ	——————————————
数据訪问层(DAL)	直接操作数据库，针对数据的增添、删除、改动、查找；详细为业务逻辑层或表示层提供数据服务。	仅仅提供主要的数据訪问。不包括不论什么业务逻辑处理。	ＡＤＯ.ＮＥＴ＋ＳＱＬ语句；ＯＲＭ框架；Ｌｉｎｑ　Ｔｏ　ＳＱＬ

 

三层结构图：

 

    说到三层，大家是不是想知道有没有两层结构。答案是有！并且就在我们身边．曾经我们的作品展，信息管理系统，第一遍机房收费。都是典型两层结构。

   两层结构图：

 

          

 

从图中就能够看出，两层结构把界面。逻辑和数据訪问统统放在了一起，互相纠缠．导致了高耦合。难复用并且当需求变更时所面临的非常可能是又一次开发．当然更别说后期的维护问题了。

 

相比于两层架构而言。三层有非常多优势：

1、开发者能够仅仅关注整个结构中的当中某一层；

2、能够非常easy的用新的实现来替换原有层次的实现；

3、能够减少层与层之间的依赖。

4、有利于标准化；

5、利于各层逻辑的复用。

6、结构更加的明白

7、在后期维护的时候。极大地减少了维护成本和维护时间

 

当然有这么多的优势，并不意味着全部的程序都须要应用三层架构，一些简单的小程序的编写全然不是必需这么复杂，而一些真正复杂的项目，三层有时候不够用，须要多层结构。

 

金无足赤。和设计模式一样，三层架构也有他的一些小缺点：

1、减少了系统的性能。这是不言而喻的。假设不採用分层式结构，非常多业务能够直接造訪数据库，以此获取对应的数据，现在却必须通过中间层来完毕。

2、有时会导致级联的改动。这样的改动尤其体如今自上而下的方向。假设在表示层中须要添加一个功能，为保证其设计符合分层式结构，可能须要在对应的业务逻辑层和数据訪问层中都添加对应的代码。

3、添加了开发成本。

基础的知识就讲到这，我们能不能从生活中找到三层的影子呢？

       我想起了有次暑假打工的经历，那是在一家酒店做的厨师助理。呵呵。这么好听的名字。说白了就是打杂的，所做的工作就是：从仓库中帮厨师找到做某道菜须要的食材。配料等。

酒店的服务工作流程是这种，服务员负责接待顾客，顾客通过菜单点了某些菜，服务员将顾客点的菜单提交给厨师。然后依据菜单所需。转告厨师助理去提取对应的原料，然后厨师将这些原料制作成美味的佳肴转交给服务员，服务员再将佳肴交给顾客。顾客在享用这些美味。

是不是有种非常熟悉的感觉，服务员，厨师，助理　不正是非常好的解释了三层架构吗？

服务员（表示层）：负责前台的工作与顾客（客户）打交道。

厨师（业务逻辑层）：负责详细制作某些菜（逻辑处理）

助理（数据訪问）：负责从仓库（数据库）中寻找某些食材配料（数据）

 知识来源于生活，联系生活来学习更有助于理解。

学了设计模式和三层才知道，作品展、学生系统、第一遍机房收费系统等都是在搭鸡窝，全部的代码都放在一个个窗口里面，并且窗口间耦合还巨强，汗。。