Wcf 开发日记 1

Wcf 开发日记

序

这篇日记是记录我在开发Wcf中所遇到的问题，以及解决的方法。这个项目并不是一个从零开发的项目，某种程度上可以被看作是从2层架构到3层的迁移。

其中遇到了很多问题，包括技术的和非技术的。这些都将会被我一一记录。这些经验和技术实践可以被用作SOA项目的参考。

 

项目的总览：

Wcf和Wpf都是MS的新技术，Wpf被用来构造新一代的UI，Wcf则是新一代分布计算的开发平台。与Com+ 不同Wcf有着学习曲线平缓，开发周期短的优势。

现在我要做的工作是将同事之前开发的Wpf + database 的 2层应用移植成为3 层的SOA。个人认为这是一种重构，这是一种从C/S => SOA的重构。

 

问题1,如何分层(How to Layer?)

3层 Presentation, Domain and Database

毫无疑问，这是被无数次企业开发实践证明过的，可行的方法。现在的问题是Domain layer(微软称之为Biz logic)内部是什么样子的。是把所有逻辑混杂在一起吗？ 我们说当然不是，fine-design是为了更好的可重用和更好的扩展。那么如何可以让我们Domain 是fine-design ？这是个问题，每个人有自己的解决方案，包括Martin Fowler 在Patterns of enterprise application architecture中 也说过，他的意见只是参考，一个好的架构师不能失去的是自己的想法和判断力。要想逻辑清晰当然要分层，我的想法是在domain内部也要分层。

第1层，也就是最外那层。当然是Service layer， 它的任务很简单负责和UI交互，提供UI所需要的一切服务。当然在UI所需要的所有接口中，可以根据逻辑和行为对它们（所有的接口函数）进行接口的划分。这样一来，可重用和扩展性都有了保障。感谢Wcf它为我们做了这一切，在Wcf中可以使用称之为Contract的概念将不同的接口函数划分成可重用的接口。

第2层 是真正的Domain Layer，这一层的实现的方法很多，最简单的方法就是使用一个类，它的每一个函数就是一个访问数据库的逻辑，当然了，它的劣势是扩展性差。如果是小型的企业应用，这种方法无疑是最好的。另一种方法复杂些，不过有着更好的扩展性。将不同的访问逻辑提取出抽象接口，根据Strategy pattern暴露给上层应用。Strategy pattern保证了良好的扩展性。即使有新的逻辑加入，所需要的也不过是一个性的逻辑类，当然这个类要实现Strategy的所有接口。

第3层

数据访问层，object to relation 的相互映射一个是一个问题。类是面向对象的而数据库是面向Record 的。无数人给出了 mapping object to relation的方法，包括Linq技术。使用.Net作为开发平台某种程度上避免了这种痛苦DataTable, DataRow and DataSet让我们的工作轻松了很多。它同时也让memory-update 成为可能。