Hi Tony Thanks for that comprehensive review
I bought the ebook, and can see that it will have a significant learning curve for me. Enough to divert into looking at LLBLGen first Cheers Kirsten _____ From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Tony McGee Sent: Thursday, 2 June 2011 6:15 PM To: ozDotNet Subject: Re: Any one using Rockford Lhotka's CSLA? We used an older version (3.0.x) it on a green field LOB Windows Forms project around 2007 targeting .NET 3.0 and then 3.5 as soon as it became available. CSLA.NET has advantages and disadvantages I guess. It's not an ORM, but can work with your choice of ORM to persist business objects. We'd would likely use it again with v4.0 for new code, but wouldn't look forward to logistics of porting a v3.0 legacy code base to the latest version when we need to move to .NET 4. Here's a mini-review, apologies for the length! Good points: - There's a fairly decent sample application and lots of little code projects that comes with the sample app showing how the library can be used with multiple UI & n-tier technologies. - It's great for providing structure to business objects that live behind CRUD screens, the n-level undo and support for ErrorProvider. In particular the databinding support was really good. In fact, the major reason we stuck with it was simplification of the plumbing code - consistent business rules and implementation of INotifyPropertyChanged. CSLA databinding (and databinding in general) is much better with WPF, and there's support for model binding in ASP.NET MVC but I haven't used it as much with those two. - The business logic framework methods allow you to perform fairly advanced logic in a structured way that automatically gets called when you change a property. CSLA v4.0 seems even better in this regard where business rules are full classes in their own right instead of just methods on the business object class. - User feedback is directly integrated into subsequent versions of the library. e.g. Property getters/setters and the business rules architecture in v3.0 heavily relied on magic strings in your class that made refactoring a pain. This has been fixed in v4.0 - The learning curve is moderate, not too bad, but not trivial either. Once you get the basics, you can keep applying the same patterns. - It's open source so in the worse case scenario so your project isn't left in the lurch if Magenic folds and you can dig deep in case things break or try to understand what's going on. Bad points: - The free documentation seems to be limited to snippets on the forum, a couple of DNR.TV episodes and the sample app. There's a print book and video series available and an ebook series in the works. The books & videos cost a little bit of money but it's comparable to buying any other 3rd part component. If you haven't used CSLA.NET before they're worth every dollar. Having said that though, the latest print book targets the 3.8(?) version of the library, which is different from the latest RTW version so you'll only be able to take the concepts away & not the code. - The library is in constant flux, and breaking changes seem to creep in a lot. So much so that we stuck with the most recent 3.0 version throughout the 3.5-3.8 releases, and now porting our business objects to 4.0 seems like it would involve almost as much effort as starting from scratch. - When we tried to apply the framework to a few scenarios where the business object wasn't backed by a database entity it would occasionally felt like the framework was a little bit rigid. There were only a few cases so we shoehorned, it but it might have been just as worthwhile to abandon it in those cases. - There are some quirks relating to what's happening under the hood (n-level undo I think), e.g. creating two separate instances of a new business object the framework would sometimes get confused as to which one was which. e.g. var c1 = Customer.NewCustomer(); var c2 = Customer.NewCustomer(); The workaround was to incorporate a Guid into the 'identity' of the object from a override method that is called by the framework if the object hadn't been saved yet. After it had been saved, returning the database assigned identity was sufficient. I might have been committing some cardinal CSLA sin here, so not sure whether it was a bug or by design or whether it's still like that in v4.0. - The difference between 'read only' business objects and 'read/write' business objects is fixed at compile time - you inherit from specific base classes. Likewise with Parent/Child business objects. The framework seems especially rigid in this regard, but I'm sure there's a reason for it, I just never understood it fully. Cheers, Tony McGee On 2/06/2011 2:57 PM, Kirsten Greed wrote: Hi All Is anyone using http://www.lhotka.net/cslanet/ I am thinking EF4 may be good for reading and writing data from tables - but not for implementing domain logic. Kirsten _____ From: ozdotnet-boun...@ozdotnet.com [mailto:ozdotnet-boun...@ozdotnet.com] On Behalf Of Greg Keogh Sent: Thursday, 2 June 2011 12:14 PM To: 'ozDotNet' Subject: RE: building the domain model - what tools to use? Folks, I've also been trying to do exactly the same thing as Kirsten in the EF4 model designer. I want to make an Entity which is a "view" of a few joined tables. You can easily make the entity and add scalar properties to it, but my attempts to map the properties to the underlying table columns doesn't work via any tricks I can find. Part of the problem is the understanding the cluttered mapping control, and part is the incomprehensible slew of compile errors that are generated. After all, I'm asking to do what ORM is designed to do, but I'm flummoxed as well. I'll try and find the relevant parts of Julia Lerman's book and read them again, and again. She must do this somewhere in the book. Greg __________ Information from ESET NOD32 Antivirus, version of virus signature database 6172 (20110601) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com __________ Information from ESET NOD32 Antivirus, version of virus signature database 6172 (20110601) __________ The message was checked by ESET NOD32 Antivirus. http://www.eset.com