why not reference wcf service from web project?

In a traditional way of thinking (remember DNA?) we're supposed to architect our application by separating layers into services. When implementing an ASP.NET MVC application, why should you really implement an extra service and wrap your WCF references into a separate dll, rather than having the web application reference the WCF directly?

I can think of two arguments, and some thoughts on those:

• Keep the code in once place (well, this is still done when you have the wCF!)
• Reusable service when other systems need the service (well, what if its internal to the application?)

On the other开发者_Go百科 hand, people might argument for over-architecture as implementing alot of layers just bring more complexity to the solution and does not yield the benefits expected.

I'm not actually a fan of introducing extra dlls just "because". Been there; ot the t-shirt with the dependency graph on it. If you can't clearly define the benefit in your environment/context, then do the simplest thing - which may well be reference from the web app.

I've heard the argument of allowing re-use, but to counter: soap/mex is already pretty-much defining this. Another argument is testability, isolation, separation etc; and it all depends on how much benefit these give you (or rather: your team) in your usage.

One very valid case for a separate dll here is when (mainly for internal apps) you are sharing a DTO library between the WCF server and client, so that both have rich objects rather than simple shadows. Bit I gather (from the tone) that this doesnt apply in this case.