Saturday, May 06, 2006

Changes in my use of CSLA

This post is copied from my post on CSLA forum.
http://groups.msn.com/CSLANET/general.msnw?action=get_message&mview=1&ID_Message=26149

It gives the other side of the same coin of my recent blog : http://survic.blogspot.com/2006/04/core-ottec-techniques.html

------------------------
Sent: 4/9/2006 1:30 AM
Subject: emit--no need of code gen; not limiting to 4 (CRUD) methods etc.
------------------------
Hi there:

After studying CSLA 1.X and 2 for a while, I am going to use emit on CSLA. I want to know interest and comment.

It will be at two levels: dataportal level and property/get/set methods level.

The direct effect is that it will reduce the need of code gen. Together with 2005’s Code Snippets, this will dramatically reduce the threshold of CSLA adoption.

Another significant benefit is that we are not limiting to 4 (CRUD) methods anymore; so, the object model will be closer to the domain logic, instead of the artifacts of 4 methods limits. Consequently, the need of special workflow objects will go away, and no need for special “criteria” and “exists” classes.

At property level, we will have cleaner property/get/set, because we do not need litter those CanRead/WriteProperty, PropertyHasChanged calls.
Also, it will be easier to add custom features without touching the framework -- effectively, it is inheritance on steroid.

The only downside is that the mechanism is too powerful and is easy to be misused. However, I feel that the above benefits are too good to be ignored.

0 Comments:

Post a Comment

Subscribe to Post Comments [Atom]

<< Home