实战 .Net 数据访问层 - 23
日期：2011-04-12 浏览次数：20431 次
u 使用现成的框架
Ø 首选当然是.NET Framework即将正式推出的ObjectSpaces！
Ø 如果希望Total Solution，Borland ECO就是最佳选择！
Ø 其它
n 开源项目推荐使用OPF（国外）
n 商业产品推荐使用Grove（国内）
u 设计自己的持久层
Ø 如果希望自己设计轮子，那么，最好的参考资料莫过于这篇文章：http://www.ambysoft.com/persistenceLayer.pdf
Ø 它山之石，可以攻玉
此处之它山，非J2EE莫属，经典案例Hibernate早已家喻户晓，您还需要等待吗？
虽然平台不同，但优秀的设计是大家共同的财富，.NET guys们快快行动起来吧！
Ø 代码是永远的老师，请多多关注这两个.NET Open Source项目：
n OPF
n OJB.NET
l 小结
u Data Access Layer在整个系统架构中的位置
这是本文最后一幅示意图，希望带给您一些帮助：
u DAF Solution之抉择篇
Ø 确定接口是关键：No. 1！
无论采用什么技术，这个总是最最关键的一步：至少，作者是这么认为的。
采用了DAF Solution后，其实已经对具体使用什么Data Access Logic技术没必要特别Care，只要接口确定，连很多历史遗留问题都可轻松解决了！
Ø 访问技术随心所欲：Just Do It！
一般做项目前，当我们设计Data Access Logic时，大都需要提前决定采用什么技术架构，如：Stored Procedure + DataSet / DataTable / DataView（Duwamish模式，结构简单，操作方便），或者SQL + Provider Factory + DataReader + Entity（PetShop模式，性能不错，可移植能力强），而采用了DAF Solution后，这些不再成为阻碍系统架构师进行Data Access Logic设计时的障碍了！
你完全可以这么做：设计时全部采用Duwamish模式，而在实现时（可能基于性能考虑）将部分Data Access Logic操作调整为PetShop模式。甚至，如果其它Layer的调用者对ADO.NET不是特别熟悉（很正常），也可以决定在某些Data Access Logic的内部使用O/R Mapping，通过Entity Façade返回后可以很轻松地以OO的方式进行后续处理！
不过，尽管如此，还是有些Issues需要具体情况具体分析：
（1） Stored Procedure在带来便利、高性能的同时，也有移植上的问题需要考虑；
（2） O/R Mapping在提高易用性的同时，也为性能、复杂度付出了一定代价；
（3） 何时采用DataReader，如何更快的访问DataSet，始终是个难以取舍的问题（虽然作者曾经对此作过断言），爱恨两难啊！
（4） 是否使用Distributed Process？安全问题又如何解决？.NET Remoting没有给出很好地解决方案，WebServices虽然有，但能保证与其它系统兼容吗？
仅举4例，可见一斑。
虽然这些现实问题都要一一解决，但在DAF这棵大树下，您还是有较大的自由度，不必再为统一架构设计而频添很多烦恼了！
Ø Storage不在话下：Data Entity Facade！
在这里，作者认为，或许称之为“Persistence不在话下”更贴切一些。
可以这么说，DAL的基石来自DAF，而DAF和外界的Bridge则是Data Entity Façade。正是其统一的外表才让我们得以自由应付随时可能发生的各种变化！
返回XML？没问题！
返回XML后不想修改调用代码？很简单，做个EntityConvert！
O/R Mapping很酷，让我返回对象吧？改一下配置文件，再写个
O/R Mapping Data Access Logic！是不是也很酷啊？
DataSet令我们的系统不堪重负，客户最近频繁投诉：您呼叫的
网页暂时没有应答，请稍后再刷，咋办呢？
这也不难：撤下DataSet，换上DataReader，Data Entity
Façade已将不同的数据访问基站构建到您的Server上，它
会确保您的系统99.98%位于服务区内（还有0.01%可能是您
忘打.NET Framework的最新Patch了，剩下的0.01%也很好
办，快去买条新内存or加个CPU吧）！
……（如您需要返回其它系统无法辨认的东东，请拨打如下免费电话：800820xxxx，DAF Solution小组将为您提供帮助……）
u n-Tier架构下n之真谛
很简单，2句话结尾：
n==?不重要，关键是：数据访问层！
若要架构好，接口是命脉！
l 参考
u MSDN
Ø .NET Framework 1.2 Documentation
Ø Longhorn SDK
Ø Data Access and Storage
Ø C# 2.0 Specification
u Design Patterns
Ø GOF 23
Ø Microsoft Patterns & Practices
u Community
Ø The Microsoft .NET Framework Community
Ø TheServerSide.NET
Ø ASP.NET Starter Kits
Ø The Code Project
Ø Dot Net Persistence
u 其它
Ø Developing the Microsoft Business Framework
Ø Borland ECO
Ø Constructor
Ø DotNetNuke
Ø Rational XDE
Ø 首选当然是.NET Framework即将正式推出的ObjectSpaces！
Ø 如果希望Total Solution，Borland ECO就是最佳选择！
Ø 其它
n 开源项目推荐使用OPF（国外）
n 商业产品推荐使用Grove（国内）
u 设计自己的持久层
Ø 如果希望自己设计轮子，那么，最好的参考资料莫过于这篇文章：http://www.ambysoft.com/persistenceLayer.pdf
Ø 它山之石，可以攻玉
此处之它山，非J2EE莫属，经典案例Hibernate早已家喻户晓，您还需要等待吗？
虽然平台不同，但优秀的设计是大家共同的财富，.NET guys们快快行动起来吧！
Ø 代码是永远的老师，请多多关注这两个.NET Open Source项目：
n OPF
n OJB.NET
l 小结
u Data Access Layer在整个系统架构中的位置
这是本文最后一幅示意图，希望带给您一些帮助：
u DAF Solution之抉择篇
Ø 确定接口是关键：No. 1！
无论采用什么技术，这个总是最最关键的一步：至少，作者是这么认为的。
采用了DAF Solution后，其实已经对具体使用什么Data Access Logic技术没必要特别Care，只要接口确定，连很多历史遗留问题都可轻松解决了！
Ø 访问技术随心所欲：Just Do It！
一般做项目前，当我们设计Data Access Logic时，大都需要提前决定采用什么技术架构，如：Stored Procedure + DataSet / DataTable / DataView（Duwamish模式，结构简单，操作方便），或者SQL + Provider Factory + DataReader + Entity（PetShop模式，性能不错，可移植能力强），而采用了DAF Solution后，这些不再成为阻碍系统架构师进行Data Access Logic设计时的障碍了！
你完全可以这么做：设计时全部采用Duwamish模式，而在实现时（可能基于性能考虑）将部分Data Access Logic操作调整为PetShop模式。甚至，如果其它Layer的调用者对ADO.NET不是特别熟悉（很正常），也可以决定在某些Data Access Logic的内部使用O/R Mapping，通过Entity Façade返回后可以很轻松地以OO的方式进行后续处理！
不过，尽管如此，还是有些Issues需要具体情况具体分析：
（1） Stored Procedure在带来便利、高性能的同时，也有移植上的问题需要考虑；
（2） O/R Mapping在提高易用性的同时，也为性能、复杂度付出了一定代价；
（3） 何时采用DataReader，如何更快的访问DataSet，始终是个难以取舍的问题（虽然作者曾经对此作过断言），爱恨两难啊！
（4） 是否使用Distributed Process？安全问题又如何解决？.NET Remoting没有给出很好地解决方案，WebServices虽然有，但能保证与其它系统兼容吗？
仅举4例，可见一斑。
虽然这些现实问题都要一一解决，但在DAF这棵大树下，您还是有较大的自由度，不必再为统一架构设计而频添很多烦恼了！
Ø Storage不在话下：Data Entity Facade！
在这里，作者认为，或许称之为“Persistence不在话下”更贴切一些。
可以这么说，DAL的基石来自DAF，而DAF和外界的Bridge则是Data Entity Façade。正是其统一的外表才让我们得以自由应付随时可能发生的各种变化！
返回XML？没问题！
返回XML后不想修改调用代码？很简单，做个EntityConvert！
O/R Mapping很酷，让我返回对象吧？改一下配置文件，再写个
O/R Mapping Data Access Logic！是不是也很酷啊？
DataSet令我们的系统不堪重负，客户最近频繁投诉：您呼叫的
网页暂时没有应答，请稍后再刷，咋办呢？
这也不难：撤下DataSet，换上DataReader，Data Entity
Façade已将不同的数据访问基站构建到您的Server上，它
会确保您的系统99.98%位于服务区内（还有0.01%可能是您
忘打.NET Framework的最新Patch了，剩下的0.01%也很好
办，快去买条新内存or加个CPU吧）！
……（如您需要返回其它系统无法辨认的东东，请拨打如下免费电话：800820xxxx，DAF Solution小组将为您提供帮助……）
u n-Tier架构下n之真谛
很简单，2句话结尾：
n==?不重要，关键是：数据访问层！
若要架构好，接口是命脉！
l 参考
u MSDN
Ø .NET Framework 1.2 Documentation
Ø Longhorn SDK
Ø Data Access and Storage
Ø C# 2.0 Specification
u Design Patterns
Ø GOF 23
Ø Microsoft Patterns & Practices
u Community
Ø The Microsoft .NET Framework Community
Ø TheServerSide.NET
Ø ASP.NET Starter Kits
Ø The Code Project
Ø Dot Net Persistence
u 其它
Ø Developing the Microsoft Business Framework
Ø Borland ECO
Ø Constructor
Ø DotNetNuke
Ø Rational XDE
免责声明： 本文仅代表作者个人观点，与爱易网无关。其原创性以及文中陈述文字和内容未经本站证实，对本文以及其中全部或者部分内容、文字的真实性、完整性、及时性本站不作任何保证或承诺，请读者仅作参考，并请自行核实相关内容。
