Comply to ObjectDataSource--Object creation
This should not be something new to great ASP.NET devs; however, just in case :)
ObjectDataSource is designed to work with classes in the business layer of the application. An instance of the business class is created (via reflection) for each and every operation performed and destroyed shortly after the operation is complete.
In case of business objects particularly expensive to initialize, you can resort to static methods or you can implement a custom caching or pooling mechanism.
Instances of the business object are not automatically cached or pooled. Both options, though, can be manually implemented by properly handling the ObjectCreating and ObjectDisposing events on an ObjectDataSource control. The ObjectCreating event fires when the data source control needs to get an instance of the business class. You can write the handler to retrieve an existing instance of the class and return that to the data source control.
public void OnObjectCreating(object sender, ObjectDataSourceEventArgs e)
{
BusinessObject bo = RetrieveBusinessObjectFromPool();
if (bo == null)
bo = new BusinessObject();
e.ObjectInstance = bo;
}
Likewise, in ObjectDisposing you store the instance again and cancel the disposing operation being executed.
public void OnObjectDisposing(object sender, ObjectDataSourceDisposingEventArgs e)
{
ReturnBusinessObjectToPool(e.ObjectInstance);
e.Cancel = true;
}
From the ObjectDataSource perspective, it makes no difference. Given the internal implementation, you perhaps save a few IL operations if you have static methods. However, having static methods on the BLL/DAL may pose issues at another level.
What if you test a business class that calls the DAL internally and the DAL fails. Can you figure out what really happened? Does the business class work or not? To effectively test a business layer that calls into a DAL you need to focus on the object under test. Mock objects come to the rescue. Mock objects are programmable, polymorphic objects that present themselves as others and can wrap DAL anomalies and signal them out clearly making the test succeed if nothing else happens. The point is that some mocking toolkits typically don’t like static methods and don't offer proper support.