我为一个有点落伍的大型州政府机构工作。我们的技能已经过时，预算冻结阻止了对新员工/顾问的任何培训或雇用（解雇人员也是不可能的）。设计业务对象、实现设计模式、建立代码库和服务、单元测试、源代码控制等都是您在这里找不到的事情。我们在 Joel 测试中的得分尽可能为 0。好消息是我们只能从这里上去！
我们开发直接通过 ODBC 连接访问 Oracle 数据库的桌面 CRUD 应用程序（使用 C++、C# 或 Java）。我们基本上在 GUI 上散布着 SQL 语句和拼凑代码。我们被告知要转向面向服务的 n 层架构，以防止直接访问数据库并消除用户计算机上的 Oracle 客户端需求。
WCF 是我们应该走的路吗？我们已经完成了一些 n 层应用程序演练（例如这个），它们似乎很容易实现，但我们只是不知道我们是否正在考虑正确的技术。利用 .NET 生成的类型化 DataSet 似乎是一个不错的权宜之计，可以节省我们数月/数年的工作（而不是从头开始为众多项目创建新的业务对象）。这种罐装方法在第一步是否可行？
我最近开始在一些 Web 应用程序中为我的数据层使用 WCF 服务，我必须说，一开始（第一周左右）这很令人沮丧，但是一旦部署了代码，这是完全值得的。
您应该首先使用现有的小型应用程序进行尝试，或者进行概念验证，以确保它符合您的需求。
从您所处环境的描述来看，我相信您几乎会立即意识到它的好处。
我工作的最后一家公司选择 WCF 的原因几乎与您上面描述的完全一样。WCF 有很多好的文档和书籍，它相对容易上手，而且 WCF 支持很多配置选项。
当您开始尝试使 WCF 以非专门设计的开箱即用方式工作时，可能会有些头疼。这些通常是配置问题。但是像这样的网站或IDesign可以帮助你完成这些。
首先，我绝对不会（抱歉强调）担心使用 typedDataSet与创建自己的业务对象相比会节省多少时间。这通常不是您花费大部分开发时间的地方。我更喜欢自己使用业务对象。
在您的情况下，我想先实施概念验证。解决您可能遇到的所有问题的解决方案。这个概念验证应该实现一个完整的用例，从客户端开始，从数据库中检索数据并将其返回给客户端。在继续之前，您应该对自己的实施充满信心。
然后是技术的选择。WCF 绝对是您的客户端应用程序和服务层之间通信的一个不错的选择。我想您的客户端和服务层都将成为 C# 应用程序？这使事情变得容易多了，因为不同平台（例如 Java/C#）之间的互操作性仍然不是微不足道的，尽管它应该在大多数情况下都可以工作。
结合 .NET 3.5 SP1 查看实体框架（因为已经有几个可用的 Oracle 提供程序），它启用了 EF 生成的类的内置 WCF 序列化。
这是一个很好的入门博客：http: //blogs.msdn.com/dsimmons
CSLA可能非常适合您的 N 层桌面应用程序。它支持 WCF，拥有庞大的开发社区，并且有据可查。它非常面向对象。