Questions on CSLA:

1. can it work with NHibernate as the DAL layer ?
2. what type of unit of work does it have ?

Where can I get an overview of it's capability ?

Thanks

Rocky,

Any chance you can provide some more detail regarding the System.ComponentModel.DataAnnotations enhancements?
Would be good to see some example code and explanation of the implementation to gauge how efficient it is. I would imagine you are using statics off the type rather than evaluating attributes per instance of a class.

Also is there any way to register custom rules delegates for use with common annotations like [Required()]?
For example I use my own custom Required static rather than the Csla one for most of my validation.
How would I be able to hook this up to the Required data annotation attribute through Csla?

Cheers

Paul

Yes, you can use nHinbernate as a DAL. To get more information about CSLA .NET please go to www.lhotka.net/cslanet and www.lhotka.net/cslanet/faq/ - and you might consider buying the "Expert 2008 Business Objects" book, which has information about CSLA .NET as well as general .NET architecture and coding concepts.

Hi,

Any thoughts on the new Client Profile in .NET 4.0? Will CSLA support this?

Maybe it’s time to separate the code into several projects to make it simpler to target different environments like Mono, clients, web servers, etc (for example: csla.dll, csla.client.dll, csla.server.dll, csla.server.web.dll, csla.client.wpf.dll, csla.client.silverlight.dll)? What are your thoughts on this?

Regards
Anders

The trick with that idea is that the actual assembly name has to be the same on both sides of the wire for .NET serialization to work.

So it is (maybe) possible to have two Csla.dll files that are different, as long as they appear the same to the .NET serializer. This is what I do in CSLA .NET for Silverlight so it can communicate with CSLA .NET for Windows - but that's using my own serializer too, and I don't know if such a thing would work with the normal .NET serializers.

I should also point out that CSLA .NET 3.5 and higher do build on the client profile. You just need to use a compiler directive to do so, and that automatically filters out all the functionality that won't work without full .NET.

That is very likely the strategy that I'll be using with CSLA .NET 4.0 as well, but I suspect that more people will use this since the .NET 4.0 client profile appears to be a more practical platform than the 3.5 attempt.