I have read the Using CSLA e-book, but still have questions on which approach to take at my company for data access: encapsulated invocation or encapsulated implementation.
One of the questions we have is whether putting the DAL in a separate assembly can lead to misuse down the road by allowing future developers to use the DAL without going through the business objects, thus bypassing the business logic. (Perhaps we would need to be worried about bigger staffing issues if that were to occur...)
We are not a software shop, we have very few developers and we don't have a need to hit anything other than SQL for our apps. So we're not sure how the "pluggable" DAL benefit applies to us and whether that should be taken into consideration.
We're in the process of developing standards for how to use CSLA going forward, and we're open to either approach but would like to understand more of the pros/cons of each model and their day-to-day affects on us. Thanks.
I ended up reading more online regarding separation of concerns in addition to Rocky's e-book, and am seeing more benefit in going the invocation route and the benefits it provides. One thing that helped change my mind even in the past day is the idea of a pluggable "mock" DAL that Rocky has in his examples...very useful. Another good point was made here:
While designs which promote separation of concerns often add complexity to an application, it should be pointed out that they also remove the complexity that is generally associated with a lack of separation of concerns. For many applications, the trade-off is often between ordered complexity and disordered complexity. Applications which do not exhibit an appropriate amount of separation of concerns are often difficult to learn due to the need to understand the whole before understanding the part, and difficult to maintain and extend.
I also think one should consider that we all have an imperfect understanding of the future. I can't count the number of apps I've built over the years where we (after months or years) had to do something "simple" like switch from 2-tier to 3-tier, or from Oracle to SQL Server.
Of course we all know that such changes aren't really simple unless the application architecture and design supports making such a change.
The data portal exists because I was burned so many times early in my career by the requirement to build "a small departmental app" in a 2-tier model, only to find that the project was actually successful and all of a sudden needed to be 3-tier so it could run over a WAN.
The same thing happens quite frequently with data. Today your company might be all over SQL Server. But in a few years maybe you get a new CIO who believes in the "no-SQL" movement, or owns stock in Oracle, or whatever...
We currently use Encapsulated Implementation and here is why.
Like you, we don’t have the need to hit different databases simultaneously. This is an internal application that has been using SQL server since its inception almost 14 years ago. We are currently rewriting it and we don’t have any short or long term plans on using another type of backend database.
But even if we did change the database, it will be a move from one database type to another. The pluggable concept brings very little value to us because we don’t need to support multiple database at the *same* time.
But even if we needed to support multiple databases at the same time (Extremely uniquely for us), we could still do that using Encapsulated Implementation as in:
private void Child_Insert(Criteria criteria)
{
If(config file say use sqlServer)
Do this(criteria);
Else if(config file say use Oracle)
Do that(criteria);
Else
Display oh sh1t message.
}
It is only when you don’t have access to edit the source code that pluggable becomes important. If you were selling your product to other companies and they wanted to create their own DAL implementation (and they don’t have the source code) then pluggable DAL is pretty much the only and *by far* the most practical and easier way to go.
So what about separation of concerns? Well, doesn’t the CSLA already offer that by implementing DataPortal_XYZ? If you need the physiological benefit of physically seeing the separation of concern then why not add a partial class to your business object where you handle the DataPortal_XYZ calls? That way, it will now be located on a different file and so it is officially “separated” (not pluggable but separated).
And what about testing? To us this was probably the most compelling reason to go pluggable, it seemed like such a convenient thing to do. The thing is that at the end of the day, your integrations testing will need to include testing against the database so you are going to have to do all the work of creating the code to tear down and set up the database for each integration test and if you are already going to have to do that then…. why bother with having a pluggable testing layer? Why not test directly against the database?
The biggest issue that I know about when conduction tests against the database is speed. Testing against the database is very slow so if you have a lot of test cases that hit the database it may be a problem. We are still not sure how we are going to solve this. Our current strategy is to limit the test we do (during development) to cover only the code we touch. Another possible solution is to create a RAM drive where the test database can reside, we hope will speed things up exponentially.
I am not sure if our strategy will pay off or not, but the benefits of Encapsulated Implementation (in our case) are too good to pass up.
Perhaps we are heading to absolute disaster, I don’t know…. But I feel pretty confident about our decision. To us, the decision on what to do really depends on our own unique set of circumstances. I don't have a problem with going all out, but some times I feel that the benefits are just not there. Sorry if I am missing the point here.
I appreciate any feedback anyone would like to offer if you feel I am missing the point.
Thanks.
Copyright (c) Marimer LLC