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
** 作者简介： ** ** **
“ 本文作者张雪峰 是 毕博全球开发中心 的高级开发工程师。他目前在中国上海 毕博全球开发中心 Core/EAI 部门工作，从事 .NET 技术的研究以及相关项目的开发。可以通过 [email protected] 与他联系。 ”
返回第一段： http://www.csdn.net/develop/Read_Article.asp?id=27542 ** **