Migrating to N-Tier Architecture with WCF?

Question

I work for a large government agency that is behind the times. Our kits are outdated and budget hangs hinder any training or hiring new employees / consultants (shooting people is also impossible). Designing business objects, implementing design patterns, creating libraries and code services, unit testing, source control, etc. - all that you will not find here. We are as much as on the Joel Test, as you can get. The good news is that we can only get up from here!

We develop desktop CRUD applications (in C ++, C # or Java) that enter the Oracle database directly through an ODBC connection. We basically have a GUI filled with SQL statements and a pad code. We were told to switch to a service-oriented n-tier architecture to prevent direct access to the database and remove the need for Oracle Client on user machines.

Is there a WCF path we should follow? We did a few walkthroughs on an n-tier application (like this one ) and they seem easy to implement, but we just don’t know enough to understand if we even consider the right technologies. Using the .NET datasets created by DataSets seems like a nice stop to save us a month / year of work (as opposed to creating new business objects from scratch for numerous projects). Is this canned approach viable for the first step?

Answer 1

I recently started using WCF services for my data tier in some web applications, and I have to say that this is disappointing at first (the first week or so), but it's worth it to deploy the code.

You should try this first with a small existing application, or maybe a proof of concept, to make sure that it meets your needs.

From the description of the environment in which you are located, I am sure that you will immediately understand the benefits.

Answer 2

The last company I worked on chose WCF for almost the reason you described above. There is a lot of good documentation and books for WCF, it's relatively easy to get the job done, and WCF supports many configuration options.

When you start trying to bend the WCF, you may experience some headaches so that they do not work correctly out of the box. These are usually configuration problems. But sites like this, or IDesign can help you with this.

Answer 3

First of all, I would definitely not (sorry for the accent) worry about the time you save by typing a DataSet compared to creating your own business objects. This is usually not the place where you spend most of your development time. I prefer to use business objects myself.

In your situation, I would like to first implement the concept of proof. This is the solution to all the problems you may encounter. This proof of concept should implement the whole precedent, starting with the client, to extract data from the database and return it to the client. Before proceeding, you must be sure of your implementation.

Then about the choice of technology. WCF is definitely a good choice for communication between your client applications and the level of service. I believe that both your customers and your level of service will become C # applications? This makes the job much easier, since the interaction between different platforms (for example, Java / C #) is still not trivial, although it should work in most cases.

Answer 4

Take a look at the Entity Framework (as it already has several Oracle providers) in combination with .NET 3.5 SP1, which provides built-in WCF serialization of your generated EF classes.

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

Answer 5

CSLA may be suitable for your N-Tier desktop applications. It supports WCF, has a large developer community, and is well documented. He is very object oriented.