Let's talk about the overhead on development first. If you're using WCF services in your web app, you need proxies to access those services. Some people prefer to generate the proxies based on the WSDL of the services that will be used. In the worst case, this leads to regenerating proxies and all of the types that are defined in the WSDL every time you change a service contract or one of the types that are used by the services. If multiple people need to make changes to any of these concurrently, this easily leads to merging problems when people need to commit their changes. Another way is to share the same types on both sides (client & server), and implement your service proxies by inheriting from ClientBase and manually keeping the implementation of the proxies up to date with the definitions of their service contracts. This is better than regenerating a bunch of code all the time, but you're still writing a lot of redirection code for the purpose of, well, what exactly? Another possibility is to use dynamic proxies which automatically implement the service contracts but this increases the amount of infrastructure code you need to put in place and it's not always clear to everyone how exactly communication with the services happens. There's also a lot of WCF configuration for each service that you need to maintain, and it can quickly grow unwieldy.

Then there's the overhead on performance. I hope we can all agree that any operation that goes out of process is at least an order of magnitude slower than a similar operation that can be executed in process. First of all, there's the networking overhead (even if your services are hosted on the same machine as the web app) that you have to keep into account. Secondly, there is the cost of serializing and deserializing everything that is transferred between the client and the server. Even with the most efficient bindings and serializers, the cost of all of this quickly adds up on high-traffic web apps. That's not to say that WCF services are inherently slow. They can be very fast and efficient, but they'll never be as fast and efficient as executing that logic in process within the web app.

Finally, there's the extra overhead it introduces to the deployment phase:

• more endpoints to set up and transfer artifacts to
• more configuration
• more monitoring of endpoints
• more servers if you're not hosting the services and the web app on the same machine

Of course, people will argue that there a plenty of benefits to using a WCF service layer in a web app. The ones I hear about most often are the forced separation of business logic and UI logic and improved scalability and reliability. I really disagree that you need a physical separation of business and UI logic. I much prefer approaches where the separation is based on abstractions. A good example was recently posted by Ayende (here and here). And when it comes to scalability/reliability, a web app that isn't dependent on a WCF service layer is as easy (or even easier depending on your setup) to scale than one that is entirely dependent on WCF services. First of all, if you care about scalability/reliability your web app should already be prepared to run behind a load balancer. If you already have a load balancer in place, you can just add more web servers to your setup when needed. If you'd host the WCF services on the same machines that are hosting the web front end, you'd get less total throughput from one server than you would if that one server could just host a web app that fully executes in process (not including the database obviously). If you're hosting the WCF services on separate machines, you'd end up with more servers to handle the load and to achieve the reliability you need than you would with just being able to add more web servers to your setup. That also increases your licensing costs. And of course, it also means increased networking overhead on every service call, which also implies that the threads on your web servers will be blocked for longer periods while they wait for those service calls to return. Unless you're calling those services asynchronously, but most people simply don't. Also, if you have serious scalability and reliability requirements you're probably better off with asynchronous messaging solutions than with SOAP services.

WCF has its benefits (though I prefer Web API's or asynchronous messaging over SOAP services these days) and it has its use cases. I just don't think internal service layers for web apps is one of them.

What are the benefits that you think an internal WCF service layer brings to your web app? And what's your opinion on how they stack up versus the downsides?

Simplicity/Complexity of the application

A common mistake is to decide to use a fashionable architectural style in a project that doesn't really have enough complexity to warrant the use of said architectural style. For instance, there's no reason whatsoever to go the DDD route if your application is mostly a forms-over-data CRUD app. You won't really get any benefit from it, and you'll only increase the total cost of the required development effort. On the other hand, an application which will feature a lot of behavior in a complex domain will certainly benefit from using a DDD approach versus a data-driven approach that implements the behavior in a more procedural, transaction-script based approach. Be honest to your customer/employer and yourself and make an objective decision based on the simplicity or the complexity of the required solution that you're being paid to build. Don't let enthusiasm for a fashionable architectural style influence your decision.

Expected lifetime of the application

Some applications live for years and years, and some are only temporary solutions that will be phased out a year or two after having been put in production. Of course, some of those temporary solutions end up being used much longer than what was originally expected due to a variety of reasons but that certainly isn't always a given. Unless you're familiar enough with how things typically go at your client or your company to predict these things, your best bet is to just go with the initially expected lifetime of the application. Does a temporary solution require the best possible architecture out there, and the resulting impact that would have on the cost to build it? I'd say it most often doesn't. In these cases, there's nothing wrong with going for the approach that is simply good enough for what is required. Striving for perfection is expensive, and generally not worth it for short-term solutions. Conversely, if the solution is expected to last a long time, a solid architecture becomes more important and is worth the extra investment to (try to) get it right if that makes it possible to keep the costs of long-term development under control.

Strategic importance of the application

Some applications are meant to improve the core business of a company, while others play a more supportive role in something that isn't actually part of the company's core business. Some applications generate revenue (directly or by improving efficiency of revenue-generating activities) while others are meant to reduce costs, typically administrative in nature. Cost reduction is important, but it's not quite as important as revenue generation and that's a factor that should be taken under consideration. A strategically important application almost always warrants putting in the effort to come up with a good architecture because it's highly likely that the application will have to evolve in whichever direction the business evolves. That's not to say that the same kind of effort wouldn't be important for cost-reducing applications. But it just might be less important than you'd like to think it is. Again, good architecture increases the cost of the project, and the return on that investment in the big picture of the company should not be ignored.

Skill-level/discipline of team

Good code and good architecture requires skill and discipline. A strong team is capable of letting good architecture grow organically and keep it at a high quality level. For a mediocre team, letting it grow organically is too often a recipe for disaster. Ideally, we'd always be working with strong teams but as we all know, that simply isn't always possible. For mediocre teams, it often makes sense to put architecture in place that is more restrictive in nature and where everyone knows how the code should be structured in advance. The downside is that this typically reduces flexibility and individual creativity, and often introduces more ceremony and indirection than what many of us would ideally like to see. But it's likely that those downsides are offset by having everyone on the same page and taking some possibly difficult decisions away from people who might not be strong enough to make the right decisions. I know that sounds harsh, but that's a reality that many of us have to deal with.

Conformity/Continuity

A lot of IT departments or software development companies prefer to use the same architecture and frameworks/libraries for most (or even all) of their projects because it makes it easier to have people work on multiple projects. In this situation, it's easier to move people between projects or have them do maintenance work on a project they weren't initially involved in. While this often prevents going with the most suitable approach for every project, it does introduce a few benefits that are hard to argue with. People will need less time to get familiar with a code base. In-house training and sharing of knowledge get easier. Bringing in new people (especially for temporary assignments) also gets somewhat easier because you have a baseline of required skills/knowledge that should go a long way within the organization. A huge downside however, is that it creates an environment that will quickly frustrate creative developers. Also, when new strong developers are brought in, they could quickly tune out once they realize they got there too 'late' to have any influence on how projects are developed. The interesting part about this driver is that it is influenced by the skill-level-discipline driver, while simultaneously influencing it towards the future.

Non-functional requirements

This is the last driver on the list, but it is certainly not the least important. Obviously, architecture is greatly influenced by some important non-functional requirements. There are many factors that can have a profound influence on what the most suitable architecture of a system could be, and it's important to think about those as quickly as possible. Do you need to respond in real time? Do you need to support mobile devices? Will there be connectivity issues? Will you need to scale massively? What are the auditing requirements? Are you dependent on third-party services? Do you need to minimize resource consumption? What kind of accessibility do you have to keep into account? The list goes on and on and many of these issues can end up becoming huge problems if you don't think about them ahead of time. Of course, you can't think of everything in advance, and many non-functional requirements can be introduced during the lifetime of the application instead of being known in advance. But the more you know in advance, the better you can prepare your software for them from the beginning.

Conclusion

There is a virtually endless variety of architectural choices and styles that can influence how you develop software. And unfortunately, there's a lot of dogma surrounding it as well. I hope this post made it clear that there is no definitive 'right' or 'wrong' when it comes to architecture, and that (as pretty much everything else in this business) it all really depends

I'm sure you can think of more architectural drivers, and I'd love to hear about any that you think I've forgotten.

Of course, it really depends on the architecture of your system. If you're using services that are only used by the front-end of your system, then I'd still advise against making those entities available outside of the service boundary for reasons that I've discussed earlier. That doesn't mean that you should go the entity-mimicking-DTO-route though. In fact, entity-mimicking-DTO's introduce a few of the same downsides you'd get from exposing entities directly through your services. For an 'internal' service (i.e. only used by your application), I think it makes a lot more sense to use DTO's per service operation which are optimized for the use case that that service operation is meant to implement.

Essentially, an internal service's operations will be either queries or commands. When it comes to queries, why not just do the simplest thing possible? In most cases, it's sufficient to just return the data in the exact same form that the data will be displayed in. Quite often, that means a denormalized set of data where the data comes from more than one type of entity/table. There's no reason to send a bunch of entity-mimicking DTO's that reference each other to the client if you're going to use the data to populate a grid. Just send a list of DTO's which are already in the most optimal form. Populating those DTO's can then simply be done through straight SQL, a view, a stored procedure, a projection through your ORM, a map/reduce operation, or whatever else that makes sense. The point is that in most cases, you should just populate those DTO's as directly as you can instead of mapping to those DTO's. In this case, the DTO's offer a clear-cut benefit and don't really introduce tedious ceremony code in your codebase.

As for the commands (inserts, updates, anything that creates something or results in something happening), why even use DTO's in the first place? People will often argue that the ability to reuse the entity-mimicking-DTO's for these operations is a benefit. Personally, I don't really see the benefit. The mere presence of entity-mimicking-DTO's only encourages people to use them for the queries as well. Instead, I prefer to go with types that encapsulate all of the data relevant to the current command (the data to be inserted/updated, or whatever else the command needs). In a very simple scenario, this could be an InsertCustomerCommand type which simply has properties for the data that needs to be inserted. Nobody will be confusing these types with any other purpose than what their name communicates.

If you're building a web app where the server-side code does everything in process (i.e. without a WCF service), then you can in many cases just use the entities directly without a real drawback, though I'd recommend keeping an eye on unexpected select N+1 problems, since those will frequently come up when you're preparing your views. But even in this case, using DTO's that are optimized for the scenarios in which they're being used can really simplify the query-side of your system a lot.

There's nothing inherently wrong with DTO's if you use them to simply transfer data. If you're using them to transfer entities, you're robbing yourself of their biggest benefit while only making things more complex than they need to be.

Coming from the Microsoft world were SOAP services have for a long time been the norm in most projects, it's very interesting to see what REST is all about and how these Restful services are built. If you don't know anything about REST, you might want to check out this article by Martin Fowler first. Obviously, you don't need to read that before you can read the book but it might pique your interest. The first chapter does a great job of introducing to the architecture of the Web and how the REST architectural style fits within it. After that, you're introduced to the Restbucks example, which is used throughout the book to show you how Restful services can work.

The book then gradually starts diving deeper and deeper into the implementation of the Restful services for the Restbucks example. Everything is explained very clearly, and the authors continuously show both the requests and the responses that are going over the wire to illustrate what is going on at the HTTP level, which makes it even easier to understand everything that's being discussed. After the explanations and request/response examples, there's typically a code-based example in either Java or .NET to show how you can implement these systems. After a while i just started skipping these examples entirely because i thought they didn't really bring any added benefit. Though i'm sure some people will appreciate those examples being included as well.

Another great thing about this book is that it remains very clear and easy to follow, even though it covers a lot of ground. Here's a brief overview of the things you'll see implemented in the next couple of chapters:

• CRUD
• Hypermedia (the engine of application state transformations)
• Everything you need to know about caching
• Event-driven services with Atom
• Atom publishing
• Security: authentication as well as authorization

After that, there's a chapter on the semantic web and microformats, which i didn't find very interesting but others likely will. The final 2 chapters make for a great conclusion of the book. First, there's a pretty extensive comparison between the benefits and drawbacks of SOAP versus REST. And finally, the last chapter covers when it makes sense to use REST and when it doesn't and ends with a recap of the major selling points of using the Web as a central building block of your architecture.

I grok the REST architectural style now, and definitely like it. If you read this book with an open mind, i'd bet you'll like it a lot as well.

If you're doing Silverlight or WPF, you've no doubt come across the MVVM (Model-View-ViewModel) pattern. It seems to be the most popular client-side architecture pattern used among Silverlight/WPF developers. I find the pattern to be highly overrated, and actually have some big issues with the whole thing.

First, let's briefly cover what MVVM is about for those of you who don't know yet. MVVM virtually eliminates all of the code that would typically be placed in the code-behind file of your View (a user control, a screen, whatever) by putting all of that logic in the ViewModel. The ViewModel itself is never tightly coupled to the View. If it does have a reference to it, it's typically through an interface that the View implements instead of a reference of the actual type of the View. This increases, or better yet, introduces testability to a large part of your UI code that you normally wouldn't be able to cover with unit tests if you'd go with the traditional "put it all in the code-behind"-approach.

The ViewModel typically contains properties for the data that is to be shown in the View, and also raises notification events when the data in those properties changes. The View uses the powerful data-binding capabilities of Silverlight/WPF to bind the properties of the ViewModel to other user controls that the View is composed of. User-events that are captured by the View are sent to the ViewModel through Commands. Typically, these commands execute a method in the ViewModel which contains some kind of logic... usually to either send the updated data in the ViewModel's properties to the Model (usually a Service Layer in Silverlight, in WPF it could be either a true Domain Model or also a Service Layer), to perform some business logic in the Model, or to retrieve data from the Model so it can be placed in the ViewModel's properties so the View can bind to it.

That is, in a nutshell, how the MVVM pattern works. So why do i have issues with this? You can develop and test most of the application's logic without being dependent on a physical View and that is typically a Good Thing, no? It sure is! However, my problem with this approach is that too many responsibilities are concentrated within the ViewModel. Its main responsibilities are to facilitate databinding and to interact with the Model. And that, in my opinion, isn't very clean. In some ways, you could actually think of the ViewModel as a glorified code-behind, with the only difference being that it's not tightly coupled to the (physical) View.

In most (if not all) MVVM implementations, a ViewModel has many possible reasons to be changed. It might need to be changed because of different data-binding requirements. Then again, it might also require changes when a part of the Model is modified. Now, i'm sure many of you can agree with me when i say that two of the most important principles in software development are Seperation of Concerns (SoC) and the Single Responsibility Principle (SRP). Obviously, the ViewModel doesn't fare well when it comes to both of these principles.

Lets forget about MVVM for a second and focus on the concerns and responsibilities that a user control can have... say, a user control that shows customer information and allows the user to edit that data so it can be persisted:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• communication/interaction with the Model
• making data (from the Model) available so it can be displayed
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

Without MVVM, all of these would be taken care of in the View. Obviously, not a good idea right? After all, if it were a good idea, we'd never have had a reason to start using MVVM in the first place.

Now, with MVVM, a lot of people would divide these concerns and responsibilities like this:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

ViewModel:

• communication/interaction with the Model
• making data (from the Model) available so it can be displayed

In this case, the View still has 3 responsibilities which is still too much according to 'the guidelines', but it's not that big of a deal (though plenty of people would argue that the simple validation would be better placed in the ViewModel). You're highly unlikely to actually want to write automated tests for pure visualization anyway and the SRP is not something that you absolutely need to follow to the extreme in every single place. For the View, this is really not a problem and very much acceptable.

The ViewModel however has 2 important responsibilities in this case, and i'd argue that these 2 things should not be done in the same place. Making data available is done through data-binding. To do this, you need a set of properties and you need to raise the necessary events. In most cases, raising those events is very straightforward, but in more complex controls you might need a bit of additional logic to determine which event should be raised at what point. The other important responsibility is the communication/interaction with the Model. In most Silverlight applications, the Model will be a Service Layer. To communicate with this Service Layer, you need Service Proxies. That means that your ViewModel is essentially responsible for communicating with the Service Layer, dealing with business exceptions that might be thrown by some service calls, and dealing with technical exceptions that can occur simply because of network-related problems. Group all of those together and i don't think i'm going out on a limb here by saying that that is a lot of logic to put in one class, no?

(Sidenote: what i don't really understand is that many people who vigorously advocate adherence to SRP and SoC in their domain and business code don't seem to hold their UI code to the same standards. I do.)

At work, we do a lot of Silverlight development. We typically have around 5 Silverlight projects in active development at the same time. And it's been that way for over a year now. That equals a lot of Silverlight code that we've written and experience and knowledge that we've built up. And we haven't used MVVM for any of it. All this time, we've been using the MVP pattern (Supervising Controller variant) with a slight twist. That twist being a slimmed down version of a Presentation Model. Our Presentation Model's sole responsibility is to facilitate data-binding, and in some cases, a touch of validation is added as well.

If we go back to our previous example of the customer screen, the responsibilities and concerns would be divided like this in our MVP-PMlight approach:

View:

• visualization of the actual control (its own layout as well drawing other user controls that it is composed of)
• outputting data in the correct user controls (for instance: various textboxes)
• (simple validation) of modified/inputted data (for instance: no string values for numeric fields, etc...)

Presenter:

• communication/interaction with the Model based on the contents of the Presentation Model

Presentation Model:

• making data (from the Model) available so it can be displayed

Which leads to classes which are more focused on their task instead of trying to focus on too many things at the same time. In my opinion, this approach is much better/cleaner than MVVM. Not only is there a noticeable benefit in code quality (classes are more focused), there is also increased potential to reuse our 'light Presentation Models' in multiple controls. Testability is increased over MVVM as well since it's always easier to test classes which are focused versus testing classes which have too many responsibilities. All in all, a couple of important benefits and we still haven't thought of a real drawback compared to MVVM.

In this post, i’d like to take the chance to explain the downsides to exposing entities through services.  Though i’ll probably miss quite a few of the downsides (feel free to add to the list through comments), the ones i will mention are IMO important enough to take note of.

Exposing entities to clients means your clients are very tightly coupled to your service(s)

Entities are a part of your domain.  These entities in your domain can change for various reasons.  Sometimes because functional changes are required, but quite often also for optimizations (whether they are for performance reasons or to improve the clarity and maintainability of your domain).  Functional changes can impact your clients, though that is not necessarily the case.  Optimizations hardly ever have an impact on your clients (other than possibly improved response times from your service calls obviously).  If your service layer accepts and returns domain entities, each possible change is highly likely to have an impact on your clients.  And this impact is not cheap.  In the best case scenario, it means updating your service contracts, regenerating your service proxies and redeploying your clients.  In the worst case scenario, it means making actual changes to the code of your clients.  And for what? Because of changes that shouldn’t have impacted your clients in the first place?

Ideally, your clients are as dumb as they can be.  They should know as little as possible about the actual implementation of the domain because that implementation is simply not relevant to them.  They should present users with data and give them the option to modify that data, to trigger actions and to perform certain tasks.  They should focus squarely on those tasks and pretty much everything else is typically better suited to be done behind your service layer.  If you build your clients with no real knowledge of the actual domain model, but of DTO’s and possible actions to be performed then you can reduce the level of coupling between your clients and your services substantially.

Many of the people who prefer to expose entities often claim that going for the DTO approach introduces too much extra work and too many extra, seemingly unnecessary classes.  For starters, they don’t want to write code that maps entities to DTO’s.  First of all, the amount of code that this requires is in reality very small, not to mention very easy.  Secondly, you can just as well use a library such as AutoMapper to take that pain away from you.  And contrary to what you might think, there is a big performance gain to be had from returning DTO’s over entities, but i’ll get to that in the next section.

Entities are hardly ever the most optimal representation of data

I think we can safely say that most applications need to show data in the following 3 ways:

• In a grid view, either as a total listing of all instances of a certain type of data or the result of a search query or some kind of filtering action
• In dropdown controls or anything else that lets users select pieces of data
• In edit screens where a piece of data needs to be displayed in its entirety, perhaps even to be modified by the user

There are undoubtedly more ways in which data can be presented to the user but i think it’s safe to say that most business applications will certainly rely on the following 3 ways quite heavily.

In the case of a grid view, you’re frequently showing data that is related to more than one entity.  You’ll often need to include the name or the description of some associated entities.  So what exactly is it that you want to do in this situation?  Do you want to return a list of the main entities of the grid view, which all have their required association properties filled in so you can display the columns that you need in the grid view?  Do you actually need all of the properties of these entities (for both the main entities and the associated entities)?  Odds are high that you’re going to be returning a lot more data to the client than you actually need.  And that is what is realistically going to hurt the performance of your system.  Any piece of unnecessary data that you transmit to your clients has a cost associated with it.  The unnecessary data is retrieved from the database.  The entities are then serialized at the service end.  Then they are transmitted to the client.  Then they are deserialized by your client.  All of this is pretty costly, so the more unnecessary data that is included in this operation, the more your performance and the responsiveness of your client (not to mention your database and your server) is impacted negatively.

In the case of dropdown controls or anything else that lets users select pieces of data, you typically only need very few of the properties of that piece of data.  In many cases, the primary key and a name or a description are sufficient.  Do you really need to transmit the entire entity every time for usages like this? Again, keep in mind that all of that extra data that will never be used by your client needs to be retrieved, serialized, transmitted and deserialized again.  Surely, this is an awful waste, no? 

And then there’s the case where a piece of data needs to be displayed in its entirety.  In these cases, you will almost always need all of the properties of the entity that is displayed, but you’ll most often also need to show other data (things that can be selected, or linked to the main entity).  This other data will in most cases fall into the previous category where you’ll only need very little information about the actual entity.  If you’re smart, you’ve chosen the DTO approach to retrieve this data for the data that can be selected, and in that case, you already have all of the infrastructural code in place to project entities or data into DTO’s.  So you might as well reuse it for the main entity as well since you already have the capability to do this.

Always keep in mind that your entities will frequently either contain more data than needed, or less data than needed.  As such, it just doesn’t make much sense to expose entities to your clients since they are hardly ever optimal for client-side usage.  If you really want to think about performance, stop worrying about the supposed cost of mapping to DTO’s (which is truly negligible) and start focusing on what your actually sending to and from your service because this is far more costly than any kind of DTO-mapping really is.

Must your data really come from entities?

If you are displaying data to your user, does that data really need to come from your domain model?  Does it really need to be retrieved by populating a collection of entities to then return them to the client?  Again, keep the form of the data in mind when thinking about this.  In many cases, as i mentioned above, an entity is not the most optimal form of the data that your client needs.  So why even retrieve it through entities? Sure, asking your ORM to retrieve a set of entities based on a set of criteria is often the easiest thing to do, but if the easiest path were the best path, the overall quality of software projects wouldn’t be in the sad state that it’s in today.  If the form of the required data is not identical to the structure of an entity, it’s often far more optimal to simply populate a DTO directly from the data.  With NHibernate, you can easily do this by adding a list of projections to your query and then using a ResultTransformer to populate the DTO’s based on the direct output of the query.  In this case, no entity instance ever needs to be created when you’re just retrieving data, and no extra mapping between the entity and the DTO’s needs to be performed.  Your data access code simply retrieves the resulting data from a query, and puts that data directly in your DTO’s.  There’s no reason why usage of an ORM should prevent you from doing this.   Once again, this approach will offer far more performance benefits than avoiding DTO mapping at all costs ever can.

What about the behavior of your entities?

Do your entities have any behavior in them?  If not, they are already more of a DTO than a true entity.  In fact, if your entities have no behavior at all, you could even wonder why you’re using an ORM in the first place.  Now, behavior can mean many things.  It could mean lazy loading of associations.  It could mean actual business logic.  Obviously, lazy-loading doesn’t (and shouldn’t!) work client-side, but what about your business logic? Do you have business logic that can be executed client-side? Or is it business logic that should only be executed behind the service layer? If so, how do you make the distinction between this to prevent client-side usage from these entities? Whatever you do, you’re pretty much opening up a can of worms that really is better avoided in the first place.

How are you going to deal with technical issues?

Accepting and returning entities from services introduces a host of technical issues that can be quite substantial.  Serialization and deserialization specifically are issues that you need to be worried about.  If you’re using an ORM which does lazy-loading of associations, this will certainly cause serialization issues that you need to work around.  You can either disable lazy loading, or you can make sure that your entities are always fully initialized (as in: always have their associations fully loaded) before they are sent back to the client.  Disabling lazy-loading will cause performance problems in your service layer, either in places where you don’t expect them to be or in places that you haven’t thought of before it’s too late.  Fully loading your entities and their associates before returning them is another performance nightmare waiting to happen so that’s really not an ideal solution either.  You can try to hook into the serialization process or even the lazy-loading features of your ORM but whatever you do in that case will be a hack that will cause issues sooner or later.  And again, all of these problems can very easily be avoided with a solution which, i hope you realize by now, offers plenty more benefits than any solution where you accept/return entities in your service.

Conclusion

Every single downside to exposing entities through services are issues that i have myself encountered in past projects, either ones i’ve worked on myself, or ones that i’ve seen other people work on.  If that’s not enough for you, then maybe you’ll find it interesting to know that some of the brightest and most respected people (like Udi Dahan and Ayende for instance) in the .NET community also actively recommend against exposing entities through services because of the same downsides that i mentioned, though they could probably give you even more downsides that i forgot to cover in this post.  These downsides are not figments of anyone’s imagination.  They are very real, and you really, really ought to think twice before dismissing this advice. 

There are probably a few answers to that question, but one reason that can’t really be disputed is that a lot of the tooling that Microsoft offers to developers simply encourage this kind of stuff.  Let’s go over a little example.

I wanted to see what some of Microsoft’s recommended tools would create for me if i wanted to create a Silverlight application which uses a database.  Obviously, a Silverlight application can’t use a database directly so the application will need to communicate with a service.  The service obviously does have access to the database.  RIA Services is a solution that Microsoft seems to be pushing a lot for this specific scenario so i figured i’d give this a shot.

I created a RIA Services Class Library project in my solution and tried to add a ‘Domain Service Class’ (as the RIA Services templates call it) to the project.  If you already have a DataContext or an ObjectContext defined within the same assembly, you can immediately select the database tables that you want to expose.   So i canceled the dialog and quickly added an ADO.NET Entity Data Model to the solution for which i selected my Chinook database.  I tried to create a ‘Domain Service Class’ again and got the following window:

Well, now that sure is easy isn’t it? I can immediately select all my ‘Entities’ and i can even check whether i want to be able to edit them through the service, and apparently i can also generate associated classes for metadata (which would be useful for validation according to the tooltip).  I checked the Album table, and left the ‘Enable editing’ option unchecked.  This created a service with the following code:

I don’t know about you, but i love those TODO statements.  After all, you really do might want to consider constraining the resultset that could be returned by the GetAlbum method.   Who knows, perhaps you have certain use cases where you don’t want all of the ‘entities’ in the Album table to be returned by your ‘domain service’.  Hopefully, this service will be used by developers who are smart enough to realize that they should modify this method, instead of using client-side LINQ statements to filter the returned Album ‘entities’ as i’m sure we’ve all seen in too many Microsoft demo’s already.

It gets better if you recreate the service and check the ‘Enable editing’ option.  Now you’re ‘domain service’ will also contain the following methods:

Man, this sure is easy, isn’t it? I now have a service that offers me full CRUD access to the Album table in my database.  If i wanted to, i could now start implementing a screen in my Silverlight application which allows my users to list the albums, edit them, delete them, create new ones, etc… and i wouldn’t even have to change anything in my ‘service layer’.   The problem is that too many developers actually will do exactly that.   After all, why should they doubt any code that was generated by a tool which comes from Microsoft?  If the tool can generate this, then certainly some people actually want you to use it like this, no?  If not, why would it even generate code like this?

I’m sure this kind of stuff gets a lot of ooh’s and aah’s during the product demo’s at Microsoft events, but other than that, what good does this really bring?  Is this really the way you want people to develop their services?  Do you really want developers to pretty much expose the database as-is to remote clients?  And those TODO statements simply won’t cut it, you know that all too well.  I simply don’t think there’s any good reason to generate code like this because a lot of people will simply take it as is and use it like that directly from their client code.  Oh sure, most of them will hook up the authentication but i’m willing to bet that very few people will actually put real business logic in there.  Why would they?  The message that a lot of people will get from the resulting code is that a service is merely a way to provide CRUD for your database tables.  What’s business logic to these people?  Right, the stuff they’ll implement in their presentation layer because this service doesn’t really encourage people to consider implementing it there.

The only benefit that i can see from using RIA services is that you don’t really have to deal with your service contracts, and your operation contracts or any of that stuff.   No, we won’t be doing any of that.  We simply use a [EnableClientAccess] attribute and we’re done!  I don’t really consider that a benefit, though i can certainly understand why people would not want to deal with the pain of classic WCF services.  RIA Services is simply a solution to the wrong problem.

I haven’t looked at ADO.NET Data Services (which will be renamed to WCF Data Services in .NET 4.0) yet, but i suppose it’ll be more of the same: something that makes it incredibly easy to create services directly on top of your database data.

Seriously though: who on earth actually wants that?

I have no doubt that there are some people out there that are using RIA Services in a responsible manner and are sticking by responsible architectural guidelines.  I also have no doubt that those people are ignoring most of the tooling that is offered by Microsoft around it.  So really, why not get rid of this kind of tooling, and spend the effort that normally goes into those tools (or anything else which encourages bad practices for that matter) on providing actual guidance to the developers of your platform?  The last thing we need are more developers who think that this is ‘ok’, or projects that have been delivered based on this kind of ‘architecture’, or customers that are turned off by .NET projects because “they all have maintenance problems”.