I have implemented the Encapsulated Invocation Model successfully as described in the CSLA 4 - Data Access book, p. 89 and as described in the EncapsulatedInvokeDto solution. This implementation is great but in my opinion, the solution/example provided allows a "switchable" rather than a "pluggable" DAL. I find that the need for the application to reference all the concrete DALs beforehand breaks the very idea of what I believe a pluggable implementation should be: to use an assembly without the need to set a new reference and recompile the application.
I am going to investigate this, but as it is something I have never done before, any guidance or suggestion(s) would be appreciated.
The only reason the samples in the book reference the concrete DAL assemblies is convenience.
One way or another the DLLs need to end up in the bin directory on the server so they can be loaded dynamically. The easiest way to get the DLLs into the bin directory when building the solution is to have the web project reference those DAL projects. That way Visual Studio copies them in automatically.
In real life you wouldn't reference them, and would instead have your IT staff build deployment scripts that ensure the DLLs end up in the bin directory.
The problem with doing that in a book is that the readers of the book then have to understand my deployment scripts, etc. That just leads to a support issue for me around the book itself, as people email me asking why they can't just build and run my demo :)
Copyright (c) Marimer LLC