使用 WCF 进入 N 层架构?

发布于 2024-07-17 18:59:44 字数 609 浏览 5 评论 0原文

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

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

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

I work for a large state government agency that is a tad behind the times. Our skill sets are outdated and budgetary freezes prevent any training or hiring of new employees/consultants (firing people is also impossible). Designing business objects, implementing design patterns, establishing code libraries and services, unit testing, source control, etc. are all things that you will not find being done here. We are as much of a 0 on the Joel Test as you can possibly get. The good news is that we can only go up from here!

We develop desktop CRUD applications (in C++, C#, or Java) that hit the Oracle database directly through an ODBC connection. We basically have GUI's littered with SQL statements and patchwork code. We have been told to move towards a service-oriented n-tier architecture to prevent direct access to the database and remove the Oracle Client need on user machines.

Is WCF the path we should be headed down? We've done a few of the n-tier application walkthroughs (like this one) and they seem easy to implement, but we just don't know enough to understand if we are even considering the right technologies. Utilizing the .NET generated typed DataSets seems like a nice stopgap to save us month/years of work (as opposed to creating new business objects from the ground up for numerous projects). Is this canned approach viable for a first step?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(5

赠我空喜 2024-07-24 18:59:45

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

当您开始尝试让 WCF 以非专门设计的现成方式工作时,可能会遇到一些麻烦。 这些通常是配置问题。 但是像这样的网站或 IDesign 可以帮助您解决这些问题。

The last company I worked for chose WCF for almost the exact reason you describe above. There is lots of good documentation and books for WCF, its relatively easy to get working, and WCF supports a lot of configuration options.

There can be some headaches when you start trying to bend WCF to work in a way not specifically designed out of the box. These are generally configuration issues. But sites like this or IDesign can help you through those.

黯然#的苍凉 2024-07-24 18:59:45

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

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

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

First of all, I would definitely not (sorry for the emphasis) worry about the time you'll save using typed DataSet's versus creating your own business objects. That is usually not where you will spend most of your development time. I prefer using business objects myself.

In you're situation I would want to implement a proof-of-concept first. One that addresses all issues you may encounter. This proof-of-concept should implement an entire use case, starting on the client, retrieving data from the database and returning it to the client. You should feel confident about your implementation before continuing.

Then about choice of technology. WCF is definitely a good choice for communication between your client applications and the service layer. I suppose that both your clients as well as your service layer will become C# applications? That makes things a lot easier since interoperability between different platforms (Java/C# for example) is still not trivial although it should work in most cases.

兮子 2024-07-24 18:59:45

看一下 Entity Framework(因为已经有几个 Oracle 提供程序可用)与 .NET 3.5 SP1 结合使用,它支持 EF 生成的类的内置 WCF 序列化。

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

Take a look at Entity Framework (as there are a couple Oracle providers available for it already) in conjunction with .NET 3.5 SP1 which enables built-in WCF serialization of your EF generated classes.

Here is a good blog to get started: http://blogs.msdn.com/dsimmons

离去的眼神 2024-07-24 18:59:45

CSLA 可能非常适合您的 N 层桌面应用。 它支持 WCF,拥有大型开发社区,并且有完善的文档。 它是非常面向对象的。

CSLA might be a good fit for your N-Tier desktop apps. It supports WCF, has a large dev community, and is well documented. It is very object oriented.

尬尬 2024-07-24 18:59:44

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

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

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

I recently started using WCF services for my Data Layer in some web applications and I must say, it's frustrating at the beginning (the first week or so), but it is totally worth it once the code is deployed.

You should first try it out with a small existing app, or maybe a proof of concept to make sure it will fit your needs.

From the description of the environment you are in, I'm sure you'll realize the benefit almost immediately.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文