Software Architecture – Advice on WCF and MVC

First of all, the basics.

N-tier application: presentation, business layer, database. It is an old .NET 2.0 (WSE + WinForms) application, a bit more tightly coupled than I'd like, and the requirement is to upgrade it to a newer architecture, while at the same time eliminating the less-than-ideal design choices made 10+ years ago (e.g. use DTOs instead of datatables/DB views directly on the client etc.).

I'm thinking of going by the following design, in broad strokes:

• Create a business logic layer class that will include all business logic, validations etc., using a data access class for CRUD operations.
• Expose this BLL using a WCF service layer as a wrapper for its methods.
• Consume the WCF service by the new client (WPF probably).

To centralize all WCF-related operations in the client project, I will create a helper class that handles the connection to the WCF service and acts like a Façade to the service operations.

Now, at the same time, there will be a new Web application (MVC) that will use some of the operations defined in the BLL. However, due to outsourcing and other reasons out of the scope of this question, what I particularly don't want is for the MVC controller developer to use (or even know of) e.g. BLLAssembly.WCFOnlyMethod(). Conversely, I wouldn't want the WCF service developer to be able to use BLLAssembly.WebOnlyMethod(). I guess both of those cases can be covered by using conditional compilation symbols in the BLL assembly (e.g. WEB_ONLY / WCF_ONLY), but of course this means two different versions of it, one for each project.

So, my question is:

Given the fact that there will be a single BLL in order to maximize code reuse, what is the optimal approach for referencing the BLL from the WCF service and the MVC controller?

The WCF service will have a hard-reference to the BLL, that much I can say with relative certainty. Client-side, the helper class will have a reference to the WCF service interface, which will be implemented by the proxy. That way the WPF client is not affected by internal changes in the BLL, as it should be.

• Should the MVC controller have a hard-reference to (its version of) the BLL assembly as well?

• Should I use a WCF service for the MVC project, as discussed here (Is this breaking SOA?) or is that overkill? The production server(s) will be the same for both projects.

• Should I have the MVC controller reference an interface, instead of the actual BLL assembly? I would still need to instantiate an actual class implementing that interface, of course, so somehow the assembly should be passed to the MVC project… or I could use a WCF service (see above).

• Or should I abandon the notion of a common BLL between the projects altogether?

Thanks in advance for any advice.