Question

Okay, I’ve got this WCF service going. It has a public access, which is the main service itself (HydSQLService) which contains a DataContext for access to the database. This DataContext was generated by SQLMetal.exe, although I created a partial class to fill in the partial methods.

So this question is more about how to layer this application. At the moment, the service (i.e. the publically exposed bit) holds a reference to the DataContext object. It goes through this to access the SQL database.

I intend to add a layer between these for server side validation, but I’m not sure if I’m missing a layer or something (I’m somewhat new to all this).

So is this the right amount of layers? Is it structured correctly, or have I made some horrendous oversight? Suggestions would be welcome.

Answer 1

The answer is – as always – it depends.

To understand the pros and cons of your architecture as described, we would need to know a whole lot more about the requirements and environment that you’re working with. However, the fact that you have layers is likely a good thing. The fact that you’re thinking about this aspect of your application is definitely a good thing.

In general, we add layers to solve a few challenges:

• Separation of concerns. Having a layer handle one aspect of the application (and handle it well) is seldom a bad thing. This allows you to rip out that layer and replace it without rewriting the rest of the application.
• Testability – It’s often beneficial to test the layers in isolation (e.g. automated unit tests) that ensure that piece is working correctly.
• Abstract away common functions (data access, validation, etc). This can make the application easier to maintain. For example, not having to maintain a bunch of data access specific code in the middle of a business object layer is nice.

This sort of question is difficult to answer specifically in this context. You would a much more in depth review to get the kind of feedback / direction you’re looking for.