6

我为一个有点落伍的大型州政府机构工作。我们的技能已经过时,预算冻结阻止了对新员工/顾问的任何培训或雇用(解雇人员也是不可能的)。设计业务对象、实现设计模式、建立代码库和服务、单元测试、源代码控制等都是您在这里找不到的事情。我们在 Joel 测试中的得分尽可能为 0。好消息是我们只能从这里上去!

我们开发直接通过 ODBC 连接访问 Oracle 数据库的桌面 CRUD 应用程序(使用 C++、C# 或 Java)。我们基本上在 GUI 上散布着 SQL 语句和拼凑代码。我们被告知要转向面向服务的 n 层架构,以防止直接访问数据库并消除用户计算机上的 Oracle 客户端需求。

WCF 是我们应该走的路吗?我们已经完成了一些 n 层应用程序演练(例如这个),它们似乎很容易实现,但我们只是不知道我们是否正在考虑正确的技术。利用 .NET 生成的类型化 DataSet 似乎是一个不错的权宜之计,可以节省我们数月/数年的工作(而不是从头开始为众多项目创建新的业务对象)。这种罐装方法在第一步是否可行?

4

5 回答 5

4

我最近开始在一些 Web 应用程序中为我的数据层使用 WCF 服务,我必须说,一开始(第一周左右)这很令人沮丧,但是一旦部署了代码,这是完全值得的。

您应该首先使用现有的小型应用程序进行尝试,或者进行概念验证,以确保它符合您的需求。

从您所处环境的描述来看,我相信您几乎会立即意识到它的好处。

于 2009-04-21T20:12:50.293 回答
2

我工作的最后一家公司选择 WCF 的原因几乎与您上面描述的完全一样。WCF 有很多好的文档和书籍,它相对容易上手,而且 WCF 支持很多配置选项。

当您开始尝试使 WCF 以非专门设计的开箱即用方式工作时,可能会有些头疼。这些通常是配置问题。但是像这样的网站或IDesign可以帮助你完成这些。

于 2009-04-21T20:15:59.957 回答
2

首先,我绝对不会(抱歉强调)担心使用 typedDataSet与创建自己的业务对象相比会节省多少时间。这通常不是您花费大部分开发时间的地方。我更喜欢自己使用业务对象。

在您的情况下,我想先实施概念验证。解决您可能遇到的所有问题的解决方案。这个概念验证应该实现一个完整的用例,从客户端开始,从数据库中检索数据并将其返回给客户端。在继续之前,您应该对自己的实施充满信心。

然后是技术的选择。WCF 绝对是您的客户端应用程序和服务层之间通信的一个不错的选择。我想您的客户端和服务层都将成为 C# 应用程序?这使事情变得容易多了,因为不同平台(例如 Java/C#)之间的互操作性仍然不是微不足道的,尽管它应该在大多数情况下都可以工作。

于 2009-04-21T20:21:50.957 回答
2

结合 .NET 3.5 SP1 查看实体框架(因为已经有几个可用的 Oracle 提供程序),它启用了 EF 生成的类的内置 WCF 序列化。

这是一个很好的入门博客:http: //blogs.msdn.com/dsimmons

于 2009-04-21T20:28:38.117 回答
2

CSLA可能非常适合您的 N 层桌面应用程序。它支持 WCF,拥有庞大的开发社区,并且有据可查。它非常面向对象。

于 2009-04-22T13:18:58.393 回答