>When you take away the trappings of his framework the code is almost exactly the same as yours.

So the code is only slightly more abstract than if you just wrote the code straight up.

I still don't think that abstraction provides any real benefits to the developer of the code beyond some RAD capability that isn't exclusive to an application framework. What I mean by that is I could take an XML Schema and write two different versions of my business object:

1. one that validates a record at runtime against the schema
2. one that validates a record using code that was generated at design time from the schema

Another good approach to business objects would be reflecting on the attributes of the objects memebers to validate business rules.

Those three implementations of the class would probably be as simple to compose as a framework's implementation, plus you don't rely on 3rd party code (meaning, it will be easier to decipher by all C# developers).

My point is that, IMO, the abstraction of business rules doesn't go very deep, and that there are plenty of valid ways to enforce them all with minimal effort from a developer.

Keep in mind, that point isn't directly related to using a commercial framework or not, only that the premise "business rules need to be abstracted" is not clearly true from where I stand. I do admit that there are plenty of other aspects and features of an application that are best implemented by 3rd party componenets of some kind (whether you wish to lock into an entire framework from one provider, individually assemble the compoenents your application requires, or a combination of the two, is of course, a whole other conversation).