The learning curve of CSLA isn t too bad but be prepared to spend some time reading in the book. We have taken care of a lot of the learning curve for you by generating a DAL (Parameterized SQL or Stored Procedure support) for you, so it adds an ORM feel to CSLA only because it manages the DAL for you if you choose. But you can completely use it as just a set of BO templates. I find that active generation makes it much easier to upgrade to newer versions of CSLA as well as add functionality without having a strong need for an intermediate class.

Thanks -Blake Niemyjski (Author of the CodeSmith CSLA Templates)

CSLA is not an ORM framework. It is a framework for implementing business objects. However, there are code generators available which can generate data access code for you. The CSLA framework is based on Active Record Pattern. This pattern will not scale for large scale project. In my opinion, you should implement a prototype. The goal of the prototype should be to:

1. Define a layering Scheme
2. Unit Testability of Classes
3. How the framework plays well with other framework
4. How it fits with other OR mapping tools
5. Learning Curve

If your evaluation seems to be positive against the above items, then go for it. In short, there should be a proper justification for using such a framework. You should not go with some one s advice, rather try it out by your own.

I love CSLA.

I used it to implement some ASP.NET 2.0 applications, some very large. It s easy to understand (after you understand Root, Child and Switchable objects), but you ll rely heavily on code generation (like CodeSmith).

Main question is: do you need CSLA? What feature do you like, or you just need to use some ORM? Today, I m writing new applications with ADO.NET Entity Framework and it s more productive than CSLA.

Keep in mind CSLA isn t a metodology, but just a tool: you ll need to understand it and to tweak it when appropriate.

CSLA is a business object framework. There are many strategies for dealing with Data access - there is much overlap between ORM and data-access. I have had a lot of success using Linq-to-SQL in a Data Access Layer to simplify development. I think this is an approach that will work for you - especially given (based on your comments) your need to support both SQL Server and Oracle.

Using a seperate DAL is well documented in Rocky s book and samples on www.lhotka.net

As far as TFS - it s an ALM tool for Source Control, Project Managment and Build Automation. You would want to put the CSLA Source under source control like any other code. The simplest approach would be to include CSLA in your solution.

Another approach would be to compile it seperately and use a file reference in your projects to the CSLA.DLL. In TFS Automated build there is a property group which you could put the path to that DLL on your build server.

Lastly Rocky sells CSLA training videos on his website at http://download.lhotka.net/default.aspx?t=Core38

You can check Rocky s thoughts on SOA in the following broadcast:

http://www.slickthought.net/post/Minneapolis-Developer-Roundtable-Podcast---Talking-REST.aspx

The main thing you will need to grasp is that CSLA is a Business framework. Even though ORMs can give you basic validation (and other) features they do not IMHO really compensate for the lack of a solid business layer. You can of course use an ORM with CSLA (there is an example of using EF in the CSLA examples and NHibernate is used as an example in the CSLA Contrib project I believe) but the technologies are just complimentary.

The learning curve... well that depends on you. I found it quite easy to get started with. i think if you have a good grasp of OO you should be fine to get something basic up and running soon. The recent videos released are also very good to get yuo started.