1. Introduction to CSLA.Net
Every developer needs an easy button.
Keith Elder
Microsoft MVP
Blog:
Quicken Loans –

2. Agenda Why CSLA.Net? What is CSLA.Net? Features as a framework
Out of Order
Logical and Physical Architecture
Scalable
Component
Features as a framework
CSLA Principles
CSLA In Action
Code generation for CSLA
Validation
Binding
The first thing we are going to look at is why we care about CSLA or why we may want to care about CSLA. We’ll look at some of the problems it is trying to solve and some of the side benefits of using it.

3. Why csla.net

4. Why CSLA? Can’t share tools or libraries
No code consistency
Every team has their own internal standards
Where does validation go?
Where do authorization rules go?
Low Reusability
Can’t share tools or libraries
New Developers
How to teach them
Lack of code templates
Can’t contribute right away
Adding a developer to a project can hurt timeline
In large development teams there are usually silos. It is just inevitable. As developers shuffle through teams because of turn over or promotions, long standing code bases become hard to manage over time without standards. Standards are the key to keeping things on track. More times than not each team has their own internal standards and moving someone from team to team isn’t always that easy. Because of that there is low reusability among teams and it is hard to bring in new developers to an existing project. The reason is because the project isn’t structured the way the new person on the team thinks. CSLA helps to address these issues by providing a consistent business framework to jump start application development and create consistency among software development teams.

5. What is csla.net

6. A business object framework.
Component S
Scalable L
Logical
CSLA stands for Component Scalable Logical Architecture (click)
We are going to take the acronym and start with the bottom two items: Scalable and Logical. The reason we are going to start there is because CSLA gets its roots primarily here first and it is this part in how we build applications that makes CSLA make a lot of sense. (click) A
Architecture

7. Logical And Physical Architecture
Three logical units that make up an application.
User Interface
Objects
Objects
All applications are made up of three logical units. UI, Objects, and database. How and where we put these pieces of the application together dictate how we write our code. For example, if I am writing an application that runs on the desktop, this is pretty easy. But, if my UI is a Smart Client that interacts with a middle tier of services which then communicate to the database, I’m going to think about doing it totally different. (click)
With CSLA you really don’t have to think about how you are going to deploy the application first. These is where the terms “Logical Architecture” come into play.
Database
Interaction
Database

8. Logical And Physical Architecture
User Interface
Object
Web Deployment
Single Tier (Fat Client / Mobile)
Three Tiered Deployment
Redeploy Application
Objects
Let’s take an example of a standard Fat Client application. As developers we always start with a single tier application. Our UI, database and objects are all on our local machine. If we look at these same components that make up this application, and turn this application into a Web Application watch what happens.
(click)
The database is moved out but our UI and business objects remain on the server. This deployment scenario isn’t that hard to support, but it is hard to scale. But what if we wanted to turn this into a three tiered deployment where we introduce an application server. This is where a lot of developers get into trouble as they don’t have a good way to move from one to the next.
Let’s redeploy the application again differently.
This time we’ll deploy it to simulate a Smart Client.
The first thing we’ll do is move our business objects that are CSLA.Net objects to an Application Server. Typically we think of this as IIS.
Next we’ll move our database up to simulate an enterprise type of database.
Then we’ll connect these three layers of our application.
The question is, how does this work. To simulate how CSLA helps in this situation let’s pretend we have an object in our client. For example a user clicks on a button in the UI to view a Loan Application.
(click – object should appear in UI)
This Loan Application object needs to get its data. One important concept of CSLA is mobile objects. This means that objects can move between tiers. In this case the object will move from the UI to the App Server to hydrate itself and then return to the UI. At this point the object can be bound to controls. As we’ll see later on CSLA supports binding to Winform, WPF and Web controls seamlessly.
(click – object should move)
What you’ve just seen is an important concept to how CSLA works. We developed an application and simply redeployed the application into a different architecture. Our code didn’t have to change to support the new architecture. As we’ll see later on, all that we would do to really make this happen with CSLA is add a line to our config file so CSLA knows where the application server is.
As you can see the Logical and Physical Architecture play a key role in where CSLA gets its name. Let’s move onto the “S” which is Scalable.
(click – next slide)
Database
Database
Interaction
App Server

9. Scalable User Interface App Server s Database Cluster
Objects
Database
Interaction
Objects
Database
Interaction
The scalable part of CSLA starts to make sense now since we understand how objects cross boundaries from the UI to the Middle Tier. Scaling the application now is merely just a matter of adding more App Servers and clustering the database. The User Interface in this example may be 5,000 desktop clients running an Enterprise Line of Business Application (CRM, ERP, etc).
(click)
As you see we’ll add (click) more app servers and databases.
This same scenario even works well for large Intranet applications that are web-based whereby we need to split up our front-end of the web application to a middle tier. Given CSLA’s roots in physical architecture, you can see how this is done with ease.
Let’s now look at the last letter “C” which stands for component.
(click – next slide component)
Objects
Database
Interaction
Objects
Database
Interaction
App Server s
Database
Cluster

10. Focus on Business Requirements
Generating the Component
Component
Properties
LoanAmount
State
FICO
LoanType
Etc…
Database Interaction
Data Portal Methods
Insert
Update
Select
Delete
Security
Viewable By Banker
Viewable By Director
Employee Loan requires special token in operations
Behavior
Driven
Development
Focus on Business Requirements
Validation
LoanAmount Is Required
State Is Required
FICO is Required
LoanType Is Required
Business Rules
FICO > 620 for LoanType
LoanType in this State
LoanAmount > 100,000
Methods and Delegates
DoesClientQualify()
LoanAmountChanged
CreditScoreChanged
In CSLA, the “C” or Component is our business object and our business object is the component. They are one in the same.
There is nothing in a CSLA Business Object that you haven’t seen before. As a matter of fact there is a lot of things in these objects that you should think about but honestly, most developers skip or don’t pay attention to.
What this slide does is break down the parts of a CSLA object so you can understand what a CSLA object is made of.
The first thing we have in our objects are properties. Nothing fancy here.
(click)
The next thing we have are methods that handle Database Interaction. We call these DataPortal methods. Typical CRUD operations. These methods fetch data, persist data and so on. For those of you that are ORM fans, you can load these objects however you want. CSLA doesn’t dictate how they get loaded. You can use ADO.Net, stored procs, Nhibernate, LINQ to SQL or whatever.
These first two sections are pretty standard in a lot of objects. The next one up is Security. In other words what needs to be secured in our object. When building LOB applications it isn’t unheard of to have to deal with a lot of business centric rules. For example, only members of team X can see property X. Or maybe property X is read only to this user or group, can’t be seen at all by this group and is editable by this person.
Validation is the next group. How many of you, and be honest, actually write “real” validation for your objects before persisting them into the database? Even if you build your validation directly from your database model meaning if a column is marked not null you make it required, in a lot of scenarios we have properties that are nullable, but they can’t be null if this other piece of information is filled out.
Next up is business rules. The real meat of why we develop LOB applications to start with, to help the business. CSLA provides a common place within the object where these rules are stored. While not a huge deal within itself, it does allow developers to easily know how to change things and where as business needs change. Again, we talked about standards earlier.
Lastly are methods and delgates. These can be whatever you want, after all, this is just an object.
Because there is a standard to CSLA objects, we can generate these objects.
Basically we can generate three of these 6 buckets. We can jump start these from an XML file, stored procedure or a database table depending on what your object should hold.
What’s left are business specific things, the business requirements. And this is why we call it a business object framework.
We can even think of it in assisting with Behavior Driven Development or BDD.
Loan Business Object

11. Features of CSLA And CSLA Objects
Deployment
Build your application, decide how it is deployed later on
Binding
Automatically supports data binding for Winforms, Web, WPF
Other
Supports Workflow, WCF, and Web Services
Internally
Mobile Objects
Business logic and data access
Easily Generated
Unlimited Undos
Tracks broken business rules
Has the object changed
Behavior Object-Oriented Design
Nested Child Objects
Contact.Save();
Saves the contact and all child objects like addresses, notes, follow ups, loans, etc.

12. Csla principles

13. CSLA Concepts Editable Root Editable Child
Base Classes
Editable Root
Editable Child
Editable, “switchable” (i.e., root or child)
Editable Root Collection
Editable Child Collection
Read-only
Read-only Collection
Command Object
Name Value List
Criteria Class
Holds information used to load the object
Nested within the business object
Can have multiple criteria classes for various purposes
Data Portal
Keeps track of where objects are instantiated, as well as CRUD operations
Allows objects to move from client to app server and back
Supports Remoting, Enterprise Services (COM+), WCF and ASMX

14. Identifying your object types

15. Editable Child Objects
Loan Object Hierarchy
Root
Loan
Properties
FICO
LoanType
LoanAmount
Editable Child Objects
PrimaryBorrower
Editable Child Coll
Addresses
Editable Child
Address
CoBorrower
Read Only
CreditReport
Red – CSLA Type
Blue – Class
Green - Property
Let’s Go From Picture to Code

16. Code generation for CSLA
CSLA In action Demo
Code generation for CSLA
Validation
Binding