Introduction to CSLA.Net Every developer needs an easy button. Keith Elder Microsoft MVP Blog: http://keithelder.net/blog/ Quicken Loans – http://www.quickenloans.com

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.

Why csla.net

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.

What is csla.net

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

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

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

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

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

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.

Csla principles

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

Identifying your object types

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

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