[quotenick="omar"]

sami wrote:

Ofcourse the other option would be to totally hide the DAL from the UI, but then you have to re-create BL versions of everything (entities & entityCollections) for the UI.

I assume you make the frowny face because you don't want to write a lot of business layer objects over again...but that is why you use code generators. The DAL is generated using one click from LLBLGen. The BusinessLayer can also be quickly generated using CodeSmith w/ custom templates etc.

I highly recommend CSLA for this very purpose...and I am writing my BL right now. I have been using CSLA for years and I am pretty sure Rocky (the guy who wrote csla) would argue that this is often precisely what you want to do. (stateless issue asside of course)

His CSLA framework is meant to be a Business Layer that hides the DAL entirely from the UI. In fact he architected it that way because DAL technology is changing so rapidly while business objects aren't as much. Also because

So I am writing Business objects that use LLBLGen DAL objects to store/fetch/etc data. The business objects expose what is appropriate for the use case.

So you might have 3 business objects: - ReadOnlyEmployee - ChildEmployee - RootEmployee

All 3 have the same private variable LLBLGenDALCase which feed the public properties on my BL including IsDirty, IsNew etc.

These 3 business objects LOOK very similar from a data point of view but they ACT very differently from a behavior point of view. For instance you won't see a Save method on the ReadOnlyEmployee and all the property definitions will be ReadOnly of course. ChildEmployee cannot be saved directly...only it's parent...which again forces a certain path of workflow to take place.

This scheme also works nicely to hide LLBL's complexity from 3rd party developers or your UI developers that maybe are not as knowlegable with OO while being good at RAD. You can deploy a public object model...all those confusing LLBL methods are hidden that outsiders would never understand.

LLBLGen layer is giving me: - FAST parameterized queries :-) Hooray FRANS!! I never think about SQL again :-) - GREAT editor interface for designing my DAL - Ability to tweak performance as BL use cases require it - XML Serializeable (very nice)

CSLA business layer is giving me: - better business rules / validation engine - Great control over CRUD methods and how my objects are made, read and used - Ability to act as UOfW objects - Objects that can move themselves across network boundaries (remoting / WS / WinCF) - Work great in Smart Client & ASP

The only tricks so far: 1. how to wrap LLBL relationship classes in BL 2. how to get Oracle & SQL both from DAL 3. how to hide DAL from some would-be developer who wants to reference dll directly and get directly to the DB

Hopefully will get those figured out this week (if i want to keep my job :0 )

Sean

Did you check the Joint CSLA.NET & LLBLGen Pro framework?

Please check the http://www.jclframework.net

Walaa wrote:

Did you check the Joint CSLA.NET & LLBLGen Pro framework?

Please check the http://www.jclframework.net

No I never heard of it.

I'm going there now and doing some reading. THANKS for the tip

Wow there is a lot to learn from in the JCL framework...

But I probably won't use it because of the changing the actual CSLA framework.

I think JCL would be more useful if it was able to consume the CSLA framework as is...or at least inherit from the CSLA to change functionality.

I wrote an architecture last year on CSLA and made the mistake of changing the CSLA code directly which made it very painful to update to CSLA 2.0 or 2.1 without breaking many things.

Ultimately the most useful scenario would be to generate your DAL with LLBLGen and extend that as needed in MyDAL.dll. Then build your BL with CSLA or extended MyCSLA.

This way if LLBL or CSLA upgrades you aren't left in the dust.

But either way Bashar is a genius and I have a lot to learn

swegele wrote:

But either way Bashar is a genius and I have a lot to learn

Thank you very much!!! Finally, somebody who sees and recognizes the truth!!!

I wouldn't go the extent of proclaiming myself a genius. I may be brilliant, but still some way away from being a genius.

No, really, the JCL Framework was always a team effort, and hopefully, it will always be a team effort. Besides, Omar did almost ALL of the work

swegele wrote:

But I probably won't use it because of the changing the actual CSLA framework.

I really wish you'd reconsider.

swegele wrote:

I wrote an architecture last year on CSLA and made the mistake of changing the CSLA code directly which made it very painful to update to CSLA 2.0 or 2.1 without breaking many things.

JCL 2.4 has been architectured in a way that will allow for non-code-breaking modifications in case either underlying frameworks (CSLA & LLBL) is changed in anyway, or if we decided to add any new functionality in the future.

Maybe if you try to create a small project using JCL you'd think again about using it.

Enjoy!