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