Developing Dane

Update 10/2016 - This posting is better viewed in my new blog . Let me start by stating, emphatically: I LOVE CSLA .NET ! I first became aware of this excellent framework in 2008 when my boss dropped Rocky's book Expert C# 2008 Business Objects on my desk. In very short order I recognized the enormous benefits CSLA could provide to developers like myself who where trying to to produce great enterprise applications. The idea that I could create completely self-contained classes which would flow naturally between the various application layers and physical tiers made me fairly giddy with excitement. This excitement was reinforced by my efforts as I implemented user presentation layers for WinForms, WPF and Silverlight all based on the same business core with little impedance between the architectural layers or the physical tiers. Concerns such as validation and n-level undo were mostly handled by the CSLA framework with very little additional effort from the developer (me).

Update 10/2016 - This posting is better viewed in my new blog . I think most developers will probably relate with this frustration. I don't know how many times I've gone to add some cool new feature to an application only to find that it requires an update to some dependent project or another. Almost without fail such an update requires further updates and somewhere in the chain is one or more breaking changes. The result always seems to be that my "quick" add of the cool feature spirals out of control and ends up costing me hours of frustration as I try to get my project back to the state I started in.