Design Pattern Fun
So, I've read through the first 100 pages or so of the Folwer book (Patterns of Enterprise Application Architecture). Very good stuff, I highly recommend it. However, there is a missing pattern that no one ever seems to mention, and I have so far only seen used in the Commerce Server.NET APIs. The funny thing about it is that after using it and implementing it in a few projects, I like it much better than many competing approaches. The pattern itself is a hybrid of the table and object based patterns. In most cases, you will see two opposing views. On the one side are the object zealots, they assure you that the best thing to do is to put everything in objects, so that you can encapsulate logic, etc. On the other side, are the table zealots, they maintain that you should pass everything as a data set or data table because it is better on performance or it is easier to pass around. The third approach takes a middle ground, objects are used for instances of data (where normally a data row might be used, consider them single entity instances), while summaries are returned in data tables. The result is that you get better performance (at least if things are done properly), because you only have to pass around summary information, rather than large data that the user won't even see unless they click "details" or something, as well as you get the built in view functions of the data table for your summaries (which is very powerful). If you haven't used the view functions of data sets / table, you are missing out, as they let you easily add sorting, filtering, etc. Additionally, for the object instances, you get full type fidelity as well as being able to do things like delay loading until the request for the info, such as line items in an order (Lazy Load pattern from Fowler). In any case, you get the best of both worlds with minor consequences. So far, it is my favorite approach (and doing a lot of consulting work, I have had ample to opportunity to implement the other approaches). Although you do use compile time type safety (unless you are passing typed data sets, etc.) it is a good alternative to the lazy load pattern, because lazy load objects don't always capture the summary information you are looking for (there is also a bit of overhead using the lazy load pattern, if you are not binding your objects directly to the data row...which would generally be a pretty idea, if it wasn't for the fact that doing this disables serialization, and hence remoting, etc. because datarows are not serializable). Maybe I will write a whitepaper or article on this, because it is a very cool strategy that no one seems to talk about. Admittedly, purists on both sides would probably not like this approach very much, but purists tend to be irrational for the sake of preserving their nice neat view of the world.
6:44:57 PM 
|
|
