ObjectDataSource - a working alternative

I have blogged about the problems with ObjectDataSource control and proposed two solutions neither of which was perfect. Today I will present a complete working solution. The code and .dll for this project is accessible on two external sites: here and here.

My solution deals with the problem of partially updating an object by providing a way for a developer to provide an instance of a business object on Updating event. Values read from the form are then transferred to this object. This solves the problem with properties not present on the form are reset to default because of the fact that object is constructed by the data source control. It also solves the problem with forcing the developer to provide a default constructor for each business object.

Unfortunately having to hook up to the Updating event would mean that instead of providing a default constructor, the developer would have to code the event handling method. This would not be such a big gain. Fortunately it is not necessary to provide the business object to the Update method by means of Updating event. If an object is not provided, it is retrieved using the Select method for which we already should have an implementation shouldn't we? Indeed we have, because otherwise how would we have displayed the object for editing in the first place? The only problem is that the select method should be able to accept the same number of parameters as was specified for the DataKeyNames property of the control which was bound to the data source control. This should not pose any problems since such a method will exist anyway in most cases.

Using the control is almost identical to using the ObjectDataSource control in that it requires you to specify the Select, Update, insert and Delete methods and a type name of an object providing those methods. Methods may be static or not. I wouldn't recommend using business objects for this. Rather create a separate classes to serve as a service layer for the control. Additionally the control makes a lot better use of DataObjectMethod attribute then ObjectDataSource. If a required Select, Update, Insert or Delete method name is not specified, the control will search for this method using the mentioned attribute. It will also automatically choose the method with required number of parameters. This make it super easy to build an application really fast.

The proposed solution I'm providing has one more feature which everyone should find really useful. This feature is called InternalSort and does just that - it is a generic sorting mechanism which will sort any strongly typed collection using a property specified in the sort expression. (reverse sort is also possible by adding DESC to the sort expression - ASP.NET does it automatically).

Ok, you ask: Where is the catch? One major inconvenience in using the control is that it does not have any support in form of designer. This makes it necessary work with it using the property editor. It also does not interact very well with controls such as FormView - i.e.: FormView does not generate templates given the configured data source control - like it would when used with ObjectDataSource.

If the described solution looks like it would help in developing your applications faster, feel free to use it. I only ask for one thing: a feedback. I would appreciate any kind of feedback: from "you suck" comments through "I would change this and this" to sending me free pizzas or some other stuff :-)

As a final note I have to say that while creating the control I was using the Reflector quite a lot to get to the guts of the original ObjectDataSource control and SqlDataSource. I have also used the sources of CSLA.NET by Rockford Lhotka, where there is an implementation of the DataSource control which works with the business objects of CSLA which is therefore not very generic.