I bought Rockford Lhotka's Expert Business Objects book a while ago. In
my current project, I'm considering using a domain design model that may include
CSLA.Net elements, so I thought I'd quickly bookmark some useful resources:
I also read an interesting blog
posting by Paul Wilson, where he said the following about CSLA.Net:
"There are many styles and possible solutions in .NET -- I have used CSLA on a major
project and do not want to do so again -- but I can say the same about many other
techniques I have used in the past too...
...I would say it didn't work -- although it was a heck of a lot of work in my opinion
(still ongoing when I left). Part of that work was in removing a lot of the features
that we simply did not need and which were causing excessive memory use. Granted our
system was not typical (lots of large recordsets and on Citrix), and I blame management
for not listening better there. But the real "work" to me was in creating my business
objects, and making sure that all the dependencies were correct also. Some of that
can certainly be alleviated in many projects with code gen, but I simply believe there
are simpler ways to do things...
So I want something simple for my teams to use and learn and maintain, while still
being flexible and easy to extend. I'm simply at the place in my career where I'm
tired of the same old things -- and I strongly believe I've found better ways."
For me, there are two aspects that I'm interested in taking from CSLA.Net, the business
rules approach and the collection of errors. I am prone to changing my mind
so don't hold me to that. I want to have a framework that is obvious and simple
but where the logic lives in the business logic layer as opposed to the UI.
Our current Active Record style design pattern however tends to promote the coding
of logic in the wrong place and this is a product that has a fair amount of logic
that cannot reside in the UI. I get accused of making things too complicated,
but what I want us to create reusable (where it makes sense) and structured
solutions. Sometimes that involves a little more complexity than a Transaction
Script type design pattern.
I try to keep things as simple as is possible while still achieving reusability and modularity.
I'm only too happy to get someone over to my desk to take a look at the structure
and tell me if they find it understandable. If you call copying and pasting
the same errors err... I mean code all over the application simple, you will pay a
maintenance tax later. It's that simple. Also it appears that some people
are unable to grasp relatively simple concepts like inheritance. As soon as
you use inheritance you get told you are making the solution too complicated even
though you've reduced the delivery time and maintenance complexity (to some) dramatically.
Come on, if all the classes inherit from a base class and you can't find the logic,
have you thought of looking in the base class? That big comment telling you
that the base class collects shared information about the process surely must be a
big give away.