My personal opinion, CSLA is a good foundation framework for building various OLTP business applications. However, not all kinds of business applications can/should be built with CSLA. You should understand and evaluate CSLA to your context and/or goals and make the decision to adopt. The book from Rocky, resources on the web as well as this forum have a lot of information that can help you understand what CSLA is, how CSLA facilitates business application development, etc. Thus, the answer is both yes and no, that is very specific to your context.
Regards,
William
You qurestion is whether to use an abstraction layer between your new application and your existing CRM application/database?
I would suggest that this is exactly what you should do, yes.
Ideally you would not talk directly to another application's database though. That's always an expensive (in the long run) and fragile way to do application integration.
If your CRM system implements a set of services, you'd be far better off if you can interact with those services rather than the database directly.
If your CRM doesn't implement a set of services, odds are pretty good that the one you replace it with will have a set of services. This is the direction the industry seems to be moving.
Assuming your existing CRM doesn't expose services, what you might consider, is the idea of creating your own set of services on top of your existing CRM. Then you can build your DataPortal_XYZ methods to interact with those services.
The value here, is that when you move to another CRM, your services are your abstraction layer. You can alter your services to interact with this new CRM (either its database or its services or whatever), but you won't impact your business objects as long as you preserve the same service interface.
While a DAL or ORM also offer a layer of abstraction - they only offer it in terms of talking directly to the database. Again, that is not an ideal way to implement application integration, and this is why I bring up the idea of using a more service-oriented approach.
I would build the services using a DTO for data transfer and a factory (from the business object perspective) that hides the details.
In many cases you really don't want to incur the overhead of web services or other network protocols - you just want to make a direct call to a DLL. But in the future, who knows?
Something like this:
[Serializable]
public class Customer : BusinessBase<Customer>
{
// ...
protected override void DataPortal_Fetch(Criteria criteria)
{
using (DataService svc = DataServiceFactory.GetService<Customer>())
{
DataObjects.CustomerQuery query = new DataObjects.CustomerQuery();
Csla.Data.DataMapper.Map(criteria, query);
DataObjects.CustomerData result = svc.GetObject(query);
_id = result.Id;
_name = result.Name;
// etc...
}
}
// ...
}
I am talking about adding another layer BENEATH the business objects.
The app then looks like this:
UI
Business Objects (BO)
Data Access Layer (DAL)
Database (DB)
The DAL gets the data from the DB and puts the data into data transfer objects (DTOs). Those DTOs are then returned to the BO so the BO can load itself with data.
The BO needs to call the DAL to start this process. To do this, the BO needs to get a reference to a DAL object. To do this, it calls a factory method that is part of your DAL.
So the factory method that I mentioned earlier is NOT a standard CSLA object factory method, no. It is a factory method that you implement as part of your DAL.
If you want to be able to easily switch from one DAL to another, you should implement your DAL using a provider pattern. You'll have one DAL assembly where you implement your factory methods, but you will not implement your actual data access logic. Instead, this assembly would dynamically load (probably using Assembly.LoadFrom()) an actual DAL assembly that does implement the data access for a specific data source.
Copyright (c) Marimer LLC