We are kind of binded to the CSLA .Net architecture here. I use hibernate on a java project and loved it. CSLA is more of a objet model driven framework which I dont necessarely agree on. Theres a couple of .net features that the framework includes that are nice but im not to found of the "put everything in the object" philosophy. Also the object persistence management of the business objects is tiedius and needs to be coded has for NHibernate its all taking care of (Dirty objects, interceptors, generated ADO code etc). If im not mistaking , the CSLA author uses these following arguments from the CSLA book to promote this framework :
- scalable n-tier security architecture (passing the business object from 1 tier to the other with firewalls between tiers,
- and encapsulating everything from the UI coder.

To make a long story short, Does anyone know if it would be wise to try to incoporate NHibernate into CSLA at the Data Access level or should I just try to convince the work place to go nhibernate and have classic UI-Businnes and Data access on same machine in a web farm configuration for overload

Thankx

CSLA and NHibernate address similar needs. I wouldn't recommend trying to integrate the two. What I've found in regards to all the O/RM tools is that it's a good thing to use a generator. Whether you're making mapping files for nHibernate or whatever you have to do with CSLA, doing it by hand is tedious.

Either way, you should separate your presentation logic from your data logic. For trivial applications it doesn't really matter, but as applications get larger and more complex it becomes more imperative to buffer the presentation from the data logic.

would you have any suggestion for code gen's.

CSLA proclaims that hidding the data access code in the business object is a good thing. so in there words yes the actual data access code is hidden but "in the object " I dont know !

CSLA'a data access layer just call's the save, update , delete methods that are in the BO.

any how thx for your reply

Mygeneration is a good code generation tool that uses templates to generate business objects/mapping files for multiple O/RM tools (nhibernate, and CSLA are supported along with several others).

I'm currently in the process of developing a template based code generator based on the Domain Specific Language tools, but it's not even in the alpha stage yet.

There is nothing wrong with putting the CRUD methods on your business objects in and of itself. It's just another way of tackling the data tasks.

Again I'm not familiar with CSLA so I can't tell you if there are any pitfalls involved. Generally, you want to avoid non static (or shared) select methods on the business object. In other words, having to create a business object in order to retrieve a business object from the database is just a bad idea. I actually ran into that pitfall the first time I tried programming the DAO pattern...I thought the DAO and the DTO should be the same.

Believe me, it's not a pretty thing to have to deal with. If CSLA requires something like this, I'd argue that you try to shield the rest of your code from it.

i am currently involved in a project that is using csla and nhibernate. so far there are just some overlaps of functionalities. i also want some feedbacks on others who had taken this path.

I think that most people here don't view csla as a real or mapper.. Also, putting your dataacces in the domain object might be 'another way of tacklink the data acces problem' but you won't find many big projects doing it this way, for obvious reasons.

That said, as I understood it, csla.net is an application framework and nh is an ormapper, so why couldn't the two be perfectly integrated?