I am helping a company with a software package that will flexibly support multiple deployment scenarios. The package is written with .NET, has a well defined BLL, and utilizes SQL Server for the database.
The design calls for a clear delineation between data access and services (BLL) and UI. There are at least two UI front ends at this point (WinForms and Web). We are proposing a WCF solution to run the BLL layer which can be run on a beefy application server. This path is pretty well marked and understood at this point, and covers one of our required deployment scenarios.
The deployment scenarios are (in no particular order):
Large multi user environment with 1-n application servers all hitting a suitably sized dedicated SQL server.
Multi user environment running the UI/BLL on each individual’s machine all accessing a shared SQL server.
Single user environment with a single machine running the entire application on their box (including SQL server).
My concern is not so much with scenario (1) as much as (2) and (3). If the deployment is a flavor of type (2) or (3), WCF isn’t really buying us anything at that point and would hamper performance. Can someone suggest a way an application can be designed so that when deployed in scenario (1) it utilizes a BLL running on a application server, but in (2) or (3) where most if not all of the entire stack is on a single machine, WCF can be circumvented with more traditional calls to the BLL?
The BLL logic would remain unchanged between all scenarios. Just in (2) or (3) I would like to have the BLL DLL loaded in memory with direct calls to it w/out having to go through WCF.
I really appreciate any advice from the community on this!