- Understanding CSLA and the Factory Pattern
- Working with the DataPortal
- Key Features of CSLA Features
- The Pros and Cons of CSLA
- Conclusion
- Further Reading
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Working with the DataPortal
The ability to get and save data is core to any enterprise architecture. CSLA implements a way of managing data that makes it possible to write meaningful saving and retrieval code without ever knowing the location of the database in question or the network protocol in play. Furthermore, CSLA lets you change a data source or network protocol without ever having to refactor your source code.
Key to working with CSLA is understanding the concept of the DataPortal. The DataPortal is an ever-present framework object that manages all data access activity. This object defines a few "special methods" for controlling read and write behavior. You implement these methods in your object to satisfy the specifics of your enterprise's data schema. The DataPortal is very aware of the special methods and is always on the lookout to call them. (See Figure 2.)
)
Figure 2 The DataPortal object publishes methods that correspond to programmable, internal, data save and retrieval methods.
The DataPortal is smart enough to figure out whether an object's data is dirty and in need of saving. Also, once a business object's Save() method has been called, the DataPortal can determine whether the Save() must perform an insert of new data or an update of existing data. Because you configure the DataPortal in the consuming application's app.config or web.config file, you can change the location of the data source and the network protocol without ever having to rewrite a line of application code. (See Figure 3.)
)
Figure 3 The CSLA DataPortal determines what network protocol to use by checking the application's configuration file.
Listing 2 and Listing 3 show you the relationship between the DataPorta.Fetch<T>() method, which is defined and implemented within the CSLA framework, and the DataPortal_Fetch() method that must be implemented by objects that use the CSLA framework. DataPortal_Fetch() is one of the special methods that must be implemented within your application code if you want to take advantage of the power of the DataPortal architecture.
Listing 2 Code to make DataPortal retrieve an object's data
public static BandsList GetBandsList(string countryCode)
{
//Create a Criteria object to pass retrieval information
//to the DataPortal
Critieria criteria = new Critieria();
//The countryCode parameter defines Bands that are
//associated with a given country as defined in the datasource.
criteria.CountryCode = countryCode;
//Use the DataPortal mechanisms to make a
//BandsList collection
return DataPortal.Fetch<BandsList>(criteria);
}
Listing 3 Implementing DataPortal_Fetch() to use DataPortal.Fetch<T>()
private void DataPortal_Fetch(Critieria criteria)
{
string countryCode = string.Empty;
if(criteria != null)
{
countryCode = criteria.CountryCode;
}
using (SqlConnection cn =
new SqlConnection(MusicDataAccess.ConnectionString))
{
cn.Open();
using (SqlCommand cm = cn.CreateCommand())
{
cm.CommandType = CommandType.StoredProcedure;
if (!string.IsNullOrEmpty(countryCode))
{
cm.CommandText = "GetBandsByCountry";
cm.Parameters.AddWithValue("@CountryCode",
criteria.CountryCode);
}
else
{
cm.CommandText = "GetBands";
}
using (SafeDataReader dr = new
SafeDataReader(cm.ExecuteReader()))
{
//Use the CSLA MarkAsChild method to make this
//list a child of the Catalog
MarkAsChild();
//Use the local programmer defined Fetch method, which is
//not part of the CSLA framework to load the individual band
//information into the list.
Fetch(dr);
}
}
}
}