Sunday, November 05, 2006

Minimalist custom class approach for winform/web combined development

Recently, I "boldly explored" the dataset 2.0 world (see my recent previous blog), it is OK now, but still pretty dark. My recommendation: do not go there!

So, the best way, even for small projects (!), is to use custom classes.

The best framework for that is CSLA. However, a lot of people do not like framework(s), for various reasons (see my recent blogs). We need a no-framework-but-only-small-utilities approach – I also call it minimalist approach -- that is the content of this blog.

It is the result of my recent research:

Here is the minimalist custom class approach (you may also see this as the minimalist use of CSLA – but usually you should add the validation and error logging -- see CSLA for that):
(a) Use BindingList as the list in custom classes (ideally, should be IList, but that means much more changes to SortedBindingList; you can always do that though -- after making the minimalist changes – see below);
(b) Use CSLA’s SortedBindingList, as the “ObjectView” (“DataView). However, add changes so that it supports objects without IEditableObject, by using code from “ObjectView”.

The key is to replace CSLA’s redo with ObjectView’s, because by doing this, it is simplified, and the responsibility is moved out of the object model -- now the object model does not tie to CSLA anymore. Also, there is no strongly typed collection anymore – that thing is simply evil!
CSLA’s redo, limitations of only 4 methods (and “exists”, “criteria”) – those are the usual items that drive people away, are not used at all in those minimalist approach.

-------------------------The best thing is that, we do not even need to do the above, the following are the products that are already ready for use:

----ObjectListView (has similar but different IEditableObject as ObjectView's *****; CSLA object always implements INotifyPropertyChanged)

----BindingListView (it uses event for IEditableObject -- it can handle object that does not implement IEditableObject; but must implement INotifyPropertyChanged) *****

----Two more recent ones (but seems do not have IEditableObject? also must implement INotifyPropertyChanged),month,2006-10.aspx#aba0e393e-be64-44c1-9428-1008ea3d8a05 (This article is wonderful!! It is even better than THE databinding book by Brian Noyes – read it before you read anything on databinding – it said all I want to say, and I certainly cannot make it that concise and clear!)

Note: CSLA and THE databinding book have more info, but strangely, neither of them has the "objectview" vision -- I guess it is because both of them assume using strongly typed collections -- only people who are hand-on doing it can see how bad the strongly typed collections are (in theory, they are good, strongly typed -- you cannot be wrong with that!), and try to avoid them at all cost -- "custom class" approach must cut off this VB6 heritage.

As I said before, the root of the problem of "strongly typed collections" is from an obsolete object modeling practice: collections were used as a modeling tool. In modern OO practice, collections are always generic. All special logic goes into classes. VB6 was very weak on OO (as a matter of fact, it did not even have real OO), as a result, all later C++, smalltalk, and Java's OO experments and practices are not in the VB6's versions of OO. We need to be very careful.

Modern OO is flexible, simple (i.e. powerful), and forgiving, not limiting, not ritualistic -- always keep that in mind!

You may ask, why I put so much effort on winform databinding, because it is THE cutting edge thing. Believe it or not, it is not the web service, but the databinding! I agree with Rocky on this totally.


Post a Comment

Subscribe to Post Comments [Atom]

Links to this post:

Create a Link

<< Home