Greetings all,

I started using CSLA exactly ONE year back and from that time I though that smart objects (defined by behavior) are the ONLY way to go. A recent heated debate on the CSLA forum that involved Mr. Paul Wilson (who I think has his own O/R tool) led me to discover LLBL. I printed the help and isolated my self reading for the last two days. I started a debate with my team members about CSLA vs. O/R (standing with CSLA all the way). I knew that my team members had a soft spot for using in-line SQL in their code (coming from VB6 background) and they always throw in my face the fact that with VB6 they were 3 times as productive as opposed to the work we are doing on the companies ERP project (OK so I always made fun of their scalability..)

Now, keeping an open mind and going through what I have read in Rocky's book, one theme that I really liked with CSLA is isolating the UI developer from any sort of "smart functionality" since all that behavior would be contained in the object itself.

As somebody coming from this camp, can any of the LLBL users tell me how we could maintain this functionality separation between the UI and middle tier (other than scout’s honor that the UI developer will NOT try to add any business logic in his screen)

I am interested in any USEFUL discussion about the CSLA vs. O/R debate because frankly I am starting to see the benefits of visualizing my DB tables as entities (although the idea of NOT using stored procedures is giving me the creeps)

Omar

Greetings Omar!

I myself am new to LLBL Gen Pro and so far I really like it. I ran across CSLA earlier this year and spent a fair amount of time anxiously awaiting the updated C# version of his book and architecture. While I don't consider myself an expert on CSLA by any stretch of the imagination, I can give you some comments on our experiences.

My partner and I spent about two months this summer working on a client application. We were using some third party controls (Janus and Infragistics) that supported some of the best features of WinForms, like databinding (two-way databinding ala IEditableObject etc., not the simpler one-way databinding you find in ASP.Net). We wanted to create business objects/domain model objects since we have had a lot of exposure to OO during a 3-year stint doing J2EE.

Initially we tried to create our own custom objects. That works fine for basic functionality and binding. In order to really get the most out of the client-side functionality, we needed to implement CollectionBase, IBindingList, IEditableObject, etc. (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnadvnet/html/vbnet02252003.asp for a high-level view of what CSLA encompasses). As Frans/Otis has pointed out many times on this forum and others, implementing those interfaces is no trivial task. I scoured the internet and downloaded every sample I could get my hands on and picked them apart to find common architectures to apply to our project. The problem was there was no consistent method of implementing those architectures and even less in the way of best practices and documentation. It seems that WinForms development is somewhat of a step-child and many people don't speak highly of the future of WinForms, what with Avalon on the horizon. We were aware of CSLA during this initial approach and tried to pull features out as we needed them. We didn't see the need for everything that CSLA brought to the table and wanted to only implement what we needed.

So after a couple of weeks of effort, we were back to square one. We bought Rocky's book and used it as a reference and tried to move forward with CSLA. While I think that CSLA accomplishes what we wanted (and more than we needed), actually getting CSLA to work was another story. First, the VB codebase was constantly changing. This is to be expected, but it didn't say much for an architecture with a book behind it that was still evolving. Second, technically while it shouldn't matter whether we used C# or VB CSLA code, we wanted C# (which was pending with the book but kept getting delayed) but it was in beta and had subtle differences compared to the VB version and not officially supported. Another big gripe was that for so much effort on the architecture and the complexity and power behind, the sample project was woefully inadequate. The final difficulty was implementing the architecture itself. There is a whole book (two if you count VB and C# separately) on implementing CSLA. It shouldn't take a whole book to implement a domain model pattern within the .Net realm. We spent several weeks going down the path trying to get CSLA to work for us. The forum community around CSLA is very active but there are many people there who were just as lost as us. You can see some of our ventures into the community here: http://searchcsla.com/Details.aspx?msn_id=9287 (bmoeskau is my partner).

Our final approach was trying to work with the dataset approach and inherit from them into custom objects. There are a couple of people around the net who advocate this approach. This approach was ugly and involved a lot of going behind the auto-generated code and making changes. But if you made changes to the adapter or your database, the auto-generated dataset code was regenerated and overwrote the code. This approach sucked and we gradually became disheartened with the whole approach and WinForms/Domain Model development.

I had run across LLBL Gen Pro during all of this and had initially avoided it because it was a block-box solution and because it was not immediately obvious that the client bindable issues were addressed. Subsequent queries to Frans/Otis indicate that he has taken care of this in LLBL Gen Pro.

That is my background with CSLA and custom objects within the client/WinForms arena. We took some time off and have recently become energized with a web-based version of our original idea. Part of my renewal in spirit came from reading some discussions regarding O/R mappers and from taking the time to download and read LLBL Gen Pro's documentation. The more I read, the more I liked. However, I'm reluctant to become to ecstatic because inevitably I'll run across some issue. We are still early on in our development process and haven't put LLBL Gen Pro through all of the scenarios we will eventually cover, but I'm pretty confident that things should be fine based on Frans/Otis' responses and because I haven't seen roadblocks discussed on this forum (like on the CSLA forum).

So, to specifically address some of your questions:

omar wrote:

As somebody coming from this camp, can any of the LLBL users tell me how we could maintain this functionality separation between the UI and middle tier (other than scout’s honor that the UI developer will NOT try to add any business logic in his screen)

I started with SelfServicing but recently switched to the Adapter pattern. See my response at http://www.llblgen.com/tinyforum/Messages.aspx?ThreadID=1470 for additional details. While technically you can't ever fully limit a developer from putting logic on the presentation layer, the adapter model definitely allows for a cleaner separation.

omar wrote:

I am interested in any USEFUL discussion about the CSLA vs. O/R debate because frankly I am starting to see the benefits of visualizing my DB tables as entities (although the idea of NOT using stored procedures is giving me the creeps)

I hope this has been useful so far. In regards to stored procedures, I think Frans/Otis and others have duked it out in other forums regarding the value of stored procedures. Obviously, early on, no one used SPs. Then back in ASP, there was a movement to beat everyone over the head and convince them to use SPs because they were faster. There never was much in the way of proof beyond some quotes from Books Online and from the people behind the scenes. Granted, that carries a lot of weight, but you have to look at specific scenarios to see if SPs benefit you. The biggest problem with SPs (IMHO) is their rigidity. You could make a few SPs to do everything you wanted and have them be really complex to handle all of the different parameters that you passed in to make them do different things, Or you could have a bunch of customized queries that are tweaked to do specific tasks but you end up with a lot of them. But don't take my opinion because I don't get into the low-levels of performance. For some interesting viewpoints, read http://weblogs.asp.net/rhoward/archive/2003/11/17/38095.aspx and http://weblogs.asp.net/fbouma/archive/2003/11/18/38178.aspx. The reason why I am OK with dynamic SQL for LLBL Gen Pro is the development efficiencies gained from the tool and the fact that it is one less thing for our small shop to worry about. I'd love to be working on a huge app with millions of hits per day with terabytes of data. But I'm not. I'm sure I've got other development deficiencies which cause greater bottlenecks than dynamic SQL (for instance, our custom controls are UserControls, not ServerControls. I like working with HTML and codebehind better than I like emitting HTML through objects.).

A parting note on CSLA: I personally feel that CSLA is not too far from being an O/R mapper in some respects. I think it is almost an open source version of what an O/R mapper provides. And that is part of the problem. In this case, there is too much confusion and difficulties in implementation, that it makes it very difficult to deal with. I much prefer LLBL Gen Pro and the way it has decreased my development complexity by essentially taking a complete layer out of the picture for me.

Hope this helps. You'd think I was getting kickbacks from Frans/Otis for all of my evangelizing! I'm not and I really need to get back to my day job now!

Matt

Greetings Matt,

Thank you for taking the time to post your answer. Although your background is totally unrelated to mine (coming from a COM world), it seems we took the same path that ended at the footsteps of LLBL. I found LLBL a viable and attractive framework for the same reasons you explained. I used to advocate elegant pure OOP solutions but real life projects have taught me better. Getting the product out of the door should be high in the priorities and hence I can never under-estimate the importance of RAD and having a framework that takes that much of work off your back.

I read your posts concerning (SelfServicing or Adapter) but found the following points confusing:

In the PL, I initially would create an entity to give to the BL to process, but that was putting a lot of validation and logic in the PL. Now, I just pass the data to the BL and let it create the entity and then save it, etc. If the PL needs data, it can ask the BL for it and it will get an entity or collection in return.

If you are NOT creating any entities in the PL, then how are you passing the data to the BL?

My BL is a handful of classes specific to functional areas of the site. These classes have static methods that perform various activities for the PL. For instance, I have a Security class with a Login() method that returns a Member entity, a Calendar class with an AddEvent() method, etc. The BL is the only place that I want calling the DataAccessAdapter to process entities. It is the only place that you have to deal with predicates, prefetch paths, etc.

1- I like the idea of totally isolating the entities in the BL and NOT allowing the PL any access to them. The question that comes up then why should you use the (Adapter); wouldn't it be easier for you (as a BL developer) to deal with those friendly SelfServicing calsses?

2- If I understand your methodology correct, your are creating sealed classes with shared members in the BL to talk to the PL. How do you model these classes; as per functionality or as per object? (are you building a service class for each entity that would expose SAFE functionality to the UI or you are just building shared methods as service brokers for the UI)?

I would like very much to learn what you have went through so that hopefully I would learn a few lessons that would save me the time and effort of making some wrong decisions..

Best Regards,

Omar

Hey omar,

Disclaimer: I know nothing about CSLA other than what I read in Expert C# Business Objects.

First, you may want to check out Frans' post on his blog about to O/R map or not to O/R map.

http://weblogs.asp.net/fbouma/archive/2004/10/09/240225.aspx

I think you may find a lot of answers there.

LLBLGen Pro is a data access layer solution. As a developer, you are responsible for making sure the business framework you create encapsulates the business rules and logic and doesn't allow the presentation layer to participate where it shouldn't. LLBLGen Pro's main focus is to provide you a flexbile and robust data access layer so you can spend your time focusing on the business logic - the fun part!

As a data access layer solution, LLBLGen Pro needs to publish its interface as "Public" so you can build a separate business layer to access it. This is different than CSLA where the CRUD methods for a specific business object are private to the business object class and the DataPortal uses reflection to access those methods. So by default, CSLA's data methods are less visible than LLBLGen Pro's classes, but it's not like I couldn't use reflection in the CSLA UI layer to access your private CRUD methods I hope you don't think that you are safe in that manner because you use CSLA.

The real question is do you need an O/R mapper in your toolbox? If you do, check out Frans' post as I mentioned above to see if LLBLGen Pro works the way you want to work with data.

mattsmith321 wrote:

There is a whole book (two if you count VB and C# separately) on implementing CSLA. It shouldn't take a whole book to implement a domain model pattern within the .Net realm.

Just to be fair, the Expert C# Business Objects book is not just a "how-to" on CSLA. Much of the book teaches you a lot of key technologies (reflection, remoting, attributes, etc.) as well as teaches you the problems faced with managing the life-cycle of a business object and providing functionality to the UI layer (binding, editing, n-level undo, etc.)

Therefore, suggesting that it takes a thorough reading of the book to implement CSLA is perhaps a little misleading. The book has some really good code, ideas, and solutions to problems you can take away for your projects without using CSLA.

I am slowly doing a chapter-by-chapter summary of it that doesn't do it real justice, but I try -

http://davidhayden.com/blog/dave/archive/2004/10/04/512.aspx

Hope this helps,

Dave

omar wrote:

If you are NOT creating any entities in the PL, then how are you passing the data to the BL?

My BL is a handful of classes specific to functional areas of the site. These classes have static methods that perform various activities for the PL. For instance, I have a Security class with a Login() method that returns a Member entity, a Calendar class with an AddEvent() method, etc. The BL is the only place that I want calling the DataAccessAdapter to process entities. It is the only place that you have to deal with predicates, prefetch paths, etc.

1- I like the idea of totally isolating the entities in the BL and NOT allowing the PL any access to them. The question that comes up then why should you use the (Adapter); wouldn't it be easier for you (as a BL developer) to deal with those friendly SelfServicing calsses?

You create the Entities in the BL and pass it up to the PL via a property.

An entity using the Adapter is not tied to any database calls, so it is safe to send it to the PL. All database interaction would be done thru the BL.

Hi Fishy,

Great answer... very helpfull... all is clear now... great forum

OMAR