For the past couple of weeks we've been doing a "deep-dive" research on CSLA
4.0 and what it can do.
Just to give a backdrop context, at my place of work, we have implemented a flavor of the CSLA.NET 1.0-ish release (back in the early 2000's). It has been stripped of many of its original components (i.e. Remoting, DataPortal, among others). Our CSLA "flavor", has been mainly used as an ORM (object - relational mapper) framework not as a business object framework. Many of the teams consuming the framework have opted for using the CRUD mechanism. Very few take advantage of the n-level undo, the broken rules capabilities, or the use of more complex object graphs and business functionality. We have journeyed through our development cycles under those conditions without rocking the proverbial boat too much during that time.
Now CSLA.NET 4.0 version has been out for a while and we have picked up a book on it and started to take a new, fresh look at it. My initial reaction was to jump into coding some examples but so much has changed and matured with this new version. This version is also pushing me in a new direction about technology that I have been neglecting. C# was new for me, I was mostly a VB.NET guy. It was extremely easy to switch over, for the most part. The most difficult concepts to grasp were:
One realization during this experience is that the CSLA author, Rocky Lhotka, does not consider this framework an ORM tool. He's very specific about making that point. He considers this framework a tool for generating high quality business objects that can help an enterprise encapsulate standardized, repeatable and reusable business rules and behavior within a business domain. The framework does not advocate any particular ORM mapping strategy (although the examples on the sample code assume the use of Microsoft's Entity Framework ORM). There is so much to learn and so little time to do it in the midst of everything else that is going on in our shop. I will try to do regular posts on our experience and if you happen to catch this column and have other intersting aspects to contribute or share, please, do!
The idea is to get better at this, a little bit more, one day at a time.
Just to give a backdrop context, at my place of work, we have implemented a flavor of the CSLA.NET 1.0-ish release (back in the early 2000's). It has been stripped of many of its original components (i.e. Remoting, DataPortal, among others). Our CSLA "flavor", has been mainly used as an ORM (object - relational mapper) framework not as a business object framework. Many of the teams consuming the framework have opted for using the CRUD mechanism. Very few take advantage of the n-level undo, the broken rules capabilities, or the use of more complex object graphs and business functionality. We have journeyed through our development cycles under those conditions without rocking the proverbial boat too much during that time.
Now CSLA.NET 4.0 version has been out for a while and we have picked up a book on it and started to take a new, fresh look at it. My initial reaction was to jump into coding some examples but so much has changed and matured with this new version. This version is also pushing me in a new direction about technology that I have been neglecting. C# was new for me, I was mostly a VB.NET guy. It was extremely easy to switch over, for the most part. The most difficult concepts to grasp were:
- Lambda Expressions (it will be a while before I can call that skill "mastered")
- LINQ Expressions (here is a great set of examples that helped me get over that difficulty)
One realization during this experience is that the CSLA author, Rocky Lhotka, does not consider this framework an ORM tool. He's very specific about making that point. He considers this framework a tool for generating high quality business objects that can help an enterprise encapsulate standardized, repeatable and reusable business rules and behavior within a business domain. The framework does not advocate any particular ORM mapping strategy (although the examples on the sample code assume the use of Microsoft's Entity Framework ORM). There is so much to learn and so little time to do it in the midst of everything else that is going on in our shop. I will try to do regular posts on our experience and if you happen to catch this column and have other intersting aspects to contribute or share, please, do!
The idea is to get better at this, a little bit more, one day at a time.
No comments:
Post a Comment