3

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.

Improve this question

1 Answer 1

Reset to default
1

You can have a common BLL component, exposed as a web service quite happily. Simply expose 2 interfaces on the WCF side of things that are implemented by the same methods in the BLL. Both thick clients and the MVC website will make calls to this common WCF webservice, but each using a different interface.

So you have a Website only web service the web site can call, and another one for the thick clients. Only allow the website devs to access the first service by not giving them the security keys to access it - you'll have some form of security to prevent unauthorised users but you'll also have some for of security to restrict access to rogue applications too.

Improve this answer
4
  • Well, my instinct agrees with you. Exposing the BLL to the MVC controller as a WCF service will decouple the two projects, which is good for security, allowing the MVC devs to access only the methods defined in "their" service contract, as well as deployment. I'm just a bit concerned with the potential performance hit, as laid out in the linked post and elsewhere. Given the production environment is behind a load balancer, perhaps there could be a one-to-one assignment between the WCF services and the MVC controllers.
    – Spyros
    May 20, 2015 at 9:12
  • @Spyros I used to work in a 'microservice' architecture, performance wasn't a problem there. Sure, each call will be slower than embedding a dll, but with many users the load will be spread out, so it can work out better. Its a standard n-tier architecture that's been used for decades.
    – gbjbaanb
    May 20, 2015 at 9:18
  • Fair enough. Besides, my BLL provides mostly "low-frequency" (don't know how else to put it), DB-heavy methods, so the overhead introduced really shouldn't be an issue. That, coupled with the possibility of using named pipe binding, since the WCF service will live on the same machine, could minimize the performance hit...
    – Spyros
    May 20, 2015 at 9:41
  • So, thank you! I'm marking your answer as accepted, since that's the road I'm going to take. I'd vote it up as well but I don't have enough reputation yet. I owe you an upvote.
    – Spyros
    May 25, 2015 at 7:48

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.