下次自动登录
现在的位置:
& 综合 & 正文
基于.NET平台的分层架构实战（九）—数据访问层的第三种实现：基于NBear框架的ORM实现
前面的讨论了使用SQL语句和存储过程两种数据访问层的实现方式，这一篇里，将讨论使用ORM方式实现数据访问层的方法。
对象-关系映射（Object/Relation Mapping，简称ORM），是随着面向对象的软件开发方法发展而产生的。面向对象的开发方法是当今企业级应用开发环境中的主流开发方法，关系数据库是企业级应用环境中永久存放数据的主流数据存储系统。对象和关系数据是业务实体的两种表现形式，业务实体在内存中表现为对象，在数据库中表现为关系数据。内存中的对象之间存在关联和继承关系，而在数据库中，关系数据无法直接表达多对多关联和继承关系。因此，对象-关系映射(ORM)系统一般以中间件的形式存在，主要实现对象到关系数据库数据的映射。
目前.NET平台上有许多ORM框架可供选择，如NBear、NHibernate等等。这里我们选择NBear实现ORM。
NBear是由博客园的Teddy's Knowledge Base团队开发的一个开源框架，主要用来提高.NET平台的开发效率，其中包含了ORM、IoC、MVP等多个组件，这里仅仅用到其中的ORM功能。关于NBear的详细使用方法本文不再详述，请参考。NBear的最新版本下载地址为。
下面我们一步一步实现数据访问层的ORM实现。
1.创建实体设计工程
使用NBear实现ORM功能，首先要创建一个实体设计工程，这个工程最终不会应用到系统中，但是必须通过它来生成NBear实体类以及配置文件。
首先，我们在解决方案下新建一个工程，名字为NBearEntityDesign，并为这个工程添加到文件mon.Design.dll的引用，这个文件在NBear文件包的dist目录下。
完成后，在这个工程下新建一个C#文件，名为EntityDesign.cs，这个文件就是设计文件，根据对实体和数据库的设计，编写完整如下：
EntityDesign.cs 1using S 2using System.Collections.G 3using System.T 4using mon.D 5 6namespace NGuestBook.NBearEntityDesign 7{ 8
public interface TAdmin : Entity 9
[PrimaryKey]11
int ID { get; }12
[SqlType("nvarchar(20)")]13
string Name { get; set; }14
[SqlType("nvarchar(50)")]15
string Password { get; set; }16
public interface TComment : Entity19
[PrimaryKey]21
int ID { get; }22
[SqlType("ntext")]23
string Content { get; set; }24
DateTime Time { get; set; }25
int MessageID { get; set; }26
public interface TMessage : Entity29
[PrimaryKey]31
int ID { get; }32
[SqlType("nvarchar(20)")]33
string GuestName { get; set; }34
[SqlType("nvarchar(100)")]35
string GuestEmail { get; set; }36
[SqlType("ntext")]37
string Content { get; set; }38
DateTime Time { get; set; }39
[SqlType("ntext")]40
string Reply { get; set; }41
[SqlType("nvarchar(10)")]42
string IsPass { get; set; }43
设计完后，将这个工程编译备用。
2.创建NBear专用实体类及配置文件
在NBear文件包的dist目录下，有一个NBear.Tools.EntityDesignToEntity.exe程序，打开它，点击“Browse”按钮，选择刚才编译生成的NGuestBook.NBearEntityDesign.dll文件，并在Output Namespace文本框里输入相应的命名空间，这里我们应输入“NGuestBook.NBearDAL”。然后点击“Generate Entities”按钮，这时会在底下的文本框里生成NBear专用实体类代码。
在解决方案下新建一个工程NBearDAL，用于存放所有ORM数据访问层的实现代码。在这个工程下新建Entities.cs，将刚才自动生成的代码覆盖掉这个文件的代码，专用实体类就做好了。
另外，需要给工程NBearDAL添加到mon.dll和NBear.Data.dll的引用，这两个文件都在dist目录下。
点击“Generate Configuration”按钮，这时会生成配置代码。在Web工程下新建文件NBearConfig.xml，将生成的代码复制到这个文件里保存。
最后还要修改一下Web.config文件。增加如下配置代码：
然后再在节点下增加如下项：
其中connectionString是连接字符串，根据个人不同情况进行修改。这里使用的是SQLServer2005。
因为数据库在上一篇中已经创建好了，这里就不需要创建数据库了。
3.编写转换器
这里出现了一个矛盾：业务逻辑层和表示层需要使用通用的实体类，如AdminInfo，而NBear需要使用专用实体类。怎么解决这个矛盾呢？我这里使用的方法是一个我称之为“转换器”的方法。 即为没一个实体写一个专门的转换器，实现两种实体类的转换。这里以管理员实体为例，这个转换器写在NBearDAL工程下的AdminConvertor.cs文件中。具体代码如下：
AdminConvertor 1using S 2using NGuestBook.E 3 4namespace NGuestBook.NBearDAL 5{ 6
/// 实体类转换器-管理员 8
public sealed class AdminConvertor10
/**//// 12
/// 由普通管理员实体类转化为NBear专用管理员实体类13
/// 普通实体类15
/// NBear专用实体类16
public static TAdmin CommonEntityToNBearEntity(AdminInfo commonEntity)17
TAdmin nbaerEntity = new TAdmin();19
nbaerEntity.ID = commonEntity.ID;20
nbaerEntity.Name = commonEntity.N21
nbaerEntity.Password = commonEntity.P2223
return nbaerE24
/**//// 27
/// 由NBear专用管理员实体类转化为普通管理员实体类28
/// NBear专用实体类30
/// 普通实体类31
public static AdminInfo NBearEntityToCommonEntity(TAdmin nbearEntity)32
AdminInfo commonEntity = new AdminInfo();34
commonEntity.ID = nbearEntity.ID;35
commonEntity.Name = nbearEntity.N36
commonEntity.Password = nbearEntity.P3738
return commonE39
4.实现数据访问层
做完上述工作，我们就可以来实现数据访问层了。借助于NBear框架的支持，我们可以非常方便的使用ORM方式访问数据库。关于NBear的细节，这里不再赘述，以管理员为例，具体代码如下：
AdminDAL.cs
2using System.Collections.G
3using System.T
5using NGuestBook.IDAL;
6using NGuestBook.E
8using NBear.D
9 10namespace NGuestBook.NBearDAL 11<
&&&&推荐文章:
【上篇】【下篇】以AWS和vCloud为标杆看四大开源平台的定位
发表于 13:03|
来源opennebula.org|
作者Ignacio M. Llorente
摘要：很多观点认为四大云平台并不会产生许多直接竞争，因为云计算的市场非常广阔。来自OpenNebula的董事兼CEO Ignacio M. Llorente从全新的角度对开源云平台的定位做了分析，他将云服务通过灵活性和应用场景两个轴线划分出四个象限。CSDN对其进行了摘译。
【CSDN编译】在过去的5年间，自从2008年三月推出首个OpenNebula的开源版以来，我们做了许多展示，并探讨了OpenNebula与其它开源云平台（Eucalyptus、OpenStack）的对比。一般的理解认为，所有开源云平台都在一个市场中竞争，抢夺同样的客户。因此，人们往往轻易得出错误的结论：经过几年的残酷竞争，只会有一个赢家，市场上只剩下一家。然而，Joe
Brockmeier 却发表文章“
”，他认为：市场给各个开源云平台都留有机会，各自有不同的微环境，共同进入宽广的开源云生态系统。（扩展阅读：
四大开源平台的命运基因）
我们准备了这篇文章来描述关于不同的云应用场景的经验，以及如何精准的找到用户需求。不要期待我们用表格一项一项的罗列社区的规模、技术功能、管理架构等。我们努力聚焦在通用的方法，他们在云计算市场的整体地位，当然，我们将努力保持中立。
两种不同的云应用场景
尽管有许多方法理解云计算，但我们从两种极端的应用场景来分析：
数据中心虚拟化：被看作vCloud式的基础资源管理工具，以及将虚拟资源管理变得简化。
按需获取资源：被看作AWS式的云服务，提供工具用于支持按需提供的虚拟化资源。
我们有意采用两种最流行的产品VMware vCloud和AWS来做标杆，因为他们部署最为广泛。我们甚至会进一步指出，大多数第一个应用场景的用户的明确的表明期待替代vCloud的方式，因为vCloud太昂贵了，也因为他们不希望被锁定，或者不能满足他们的需求。同样的，第二种应用场景明确的依赖Amazon，这显然不能满足用户在内部建立云平台的需求。
下面的表格对两种应用场景的主要特征进行了描述。
数据中心虚拟化
按需获取资源
多层应用，符合“企业”的方式
需“重建”应用
功能丰富的API和管理界面
简单的云API和自制界面
完整的虚拟资源和物理资源的生命周期管理
简单的虚拟资源涉及的基本物理资源的抽象的生命周期管理
更多用于私有云
更多用于公有云
自下而上，优先考虑数据中心管理的复杂性
自上而下，优先考虑云功能的实现效率
高可用、容错，有云管理平台提供支持
大多数建立在应用内部，设计时已为失败做好准备
数据中心整合
很容易适应任何已有的基础设施
建立在新的基础设施上
这个对已存的云计算应用场景的分类并不是第一次提出。“数据中心虚拟化”和“按需获取资源”这两种应用场景也被许多分析师或媒体叫做不同的名字：如许多分析师称“企业云”和“下一代云”，Gartner分析师
Lydia Leong称“Cloud-in” 和“Cloud-out”；Cloudscaling联合创始人及CTO
称“Enterprise Cloud “和“Open Cloud”；Leading Edge Forum的分析师
Simon Wardley称“Enterprise Cloud”和“Private Cloud”；Register的
称“Private Cloud”和“Public Cloud”；VMware的工程师
称“Policy-based Clouds”和“Design for fail Clouds”，他同时还提出了“以服务于应用的架构设计”对比“为发挥最大资源效率的应用设计”的说法。
两种不同的风格的云平台
图：由灵活性和应用场景划分出了四个象限
对这个图表的评论：
Ignacio将开源云平台与其参考原型之间的差异之处称为灵活性（Flexibility），并以数据中心虚拟化、按需获取计算资源、低灵活性、高灵活
性为四象限将如上所述四个开源云平台放到不同的位置（如下图所示）。Ignacio进一步指出这个图例并不是为了说明某个开源云平台优于其他开源云平台，
而是为了说明不同的开源云平台适用于不同的客户需求以及不同的应用场景。以目前的状况而言，私有云市场规模很大，客户需求以及应用场景之间的差别很大，并
不存在一个能够通吃所有应用场景的云平台。未来Eucalyptus、CloudStack、OpenStack和OpenNebula这四个云平台之间
既有竞争也会有合作，并在这种竞争与合作并存的关系中找准适合自己的市场和客户。
除此之外，作者还做了另外的澄清：
位置并不代表绝对的价值
你还可以用这个图表来来对比专有的云平台
任何云平台都可以用于搭建公有云或私有云，并实现云API这个图表并不是静态的，不同的云平台会向上、下、左、右移动。
，或者比较
，就像比较苹果和橘子一样。他们都是水果，但却有不同的味道。话虽这么说，自从云平台诞生后，彼此之间就存在功能的重复。未来，不同云平台间的重复功能部分将会越来越多，在图表中将显示为在“应用场景”轴的间距越来越小。
OpenNebula与Eucalyptus有着截然不同的基本价值观和目标客户，在图表中他们存在于对立的象限。我会说，他们分别代表着开源版的vCloud和AWS。同样的，许多公司会对比OpenNebula和OpenStack，因为他们都能针对用户需求提供非常灵活的方案，但这种想法错误的认为他们提供的是同样应用场景的云服务。Eucalyptus与OpenStack将会面对同一类型同样的需求。
在OpenNebula，我们不认为一种云平台会控制另外一个云平台。长期看，各个云平台会逐步聚为一点，但这不会在10年内发生。因此，也因为某一个云平台不能满足所有用户的需求，我们将看到在开源云平台中将共存几个产品，他们分别聚焦在不同的生态环境中。这是一种自然的演进，同样的事情也会在其它市场中发生。在宽广的开源云计算生态系统中，这四个开源云平台将会共存，并在一些案例中协同工作。
在一定程度上这种合作还没有真正开始。我们的一些用户报告称，他们在使用OpenNebula的同时还使用了其它云平台：
一些公司混合使用了企业云和内部云服务。他们实现了把OpenNebula建立在OpenStack或Eucalyptus上的架构。
还有一些公司使用了来自不同云平台的组件来搭建云服务。他们将OpenNebula的功能与OpenStack的Swift或Quantum集成。
我们确信，在短时间内将会看到更多开源云平台合作的项目，同时，他们也会各自拓展属于自己的市场。（编译/
责编/仲浩）
推荐阅读相关主题：
CSDN官方微信
扫描二维码,向CSDN吐槽
微信号：CSDNnews
相关热门文章_NET平台下开发三层架构WinForm应用程序简介_赵春玲_百度文库
两大类热门资源免费畅读
续费一年阅读会员，立省24元！
_NET平台下开发三层架构WinForm应用程序简介_赵春玲
上传于||暂无简介
阅读已结束，如果下载本文需要使用
想免费下载本文？
你可能喜欢