To paraphrase Rocky from the 3rd Csla 3.8 video, while discussing a demo project which invokes an abstracted DAL from within the BO (starting at about 1:10:48)
In a 3 tier model you don't even deploy your concrete data access components to the client. You simply deploy an abstract DAL router assembly. This is interesting for a couple of reasons: it simplifies client installation, completely abstracts the DAL layer making it configurable, and improves security b/c the actual code which accesses the database store is on the application server only.
Unfortunately, while the business assembly only has a reference to the abstract DAL router, the UI assembly appears to require a reference to the both the abstract DAL router and the actual DAL implementation assembly. In the demo project distributed with the video, the WPF UI project has references to the two concrete DAL implementations (ADO and Mock) and once removed, the system can no longer construct a DalManager, throwing an ArgumentNullException.
Here is to hoping that i am just missing something, as this was one of the features that I was really excited about.
Having typed this, the thought just came to me that perhaps i need to run in a true 3 tier (the demo project i believe is 2 tier). I will explore this possibility.
Any other suggestions would be greatly appreciated.
On the main project on the tier, which accesses the DB, you have to provide the conrecte implemetations of your DAL.
In a 2-tier configuration, this is where the client UI exe is, in a 3-tier configuration this is where a "server.exe" is.
In one of these project you have to:
I started thinking towards the end of my post that the demo project wasn't a true 3 tier config, thus the app.config key DalManagerType defining the DAL implementation was in the UI app.config. You confirmed my suspicions, and a true 3 tier build fixed the issue.
Copyright (c) Marimer LLC