Building a Csla.net Application Server

So. I've been using the Csla.net framework for several years now, but up until two years ago, had never looked at fully utilising the remote server aspect of the framework.

Rockford Lhotka's Csla.net framework, for those who don't know it provides a way of managing data across many different scenarios.

The general concept is... I might be wrong here, to be honest I never managed to finish reading the manual, just went straight on to the code... you shouldn't really have to worry about how your data is hosted, where it's hosted or anything like that; you should just be able to craft the logic managing your data and know that once it's been set up, it will get to and from it's home safely, easily and correctly.

Okay, so let's face it, you can't really guarantee that it's going to be safe, and definitely can't guarantee that it's going to be correct (why do we have to let users touch our data? It would be so much cleaner if we just left it where it was, :-)), but the Csla.net framework will allow you to be relatively confident that what you are getting and sending is correct and secure.

The general principle goes that you create 'Smart Data' business objects. What's a 'Smart Business object'? Think of a Person, Address or ContactDetail class or 'Business Object'. Now think of that 'Business Object' having some smarts about it. Think of how useful it would be if each 'Business Object', on request, was able to tell you if it's data is correct, if you were permitted to view it and could automatically fill in related fields in response to an entry in a single field. I.e. You enter 'Mr' into the 'Title' field and the 'Gender' field automatically updates with an 'M'. These are 'Smart' Business Objects.

It was the whole 'Smart Business Objects' that attracted me to the framework in the first place. Like I said, I'm not very good at using manuals, preferring to just get stuck into the code straight away and work out what's going on as I go along. I therefore missed the Application Server aspect of Csla.net. With Csla, you can switch it to work 'remotely', I.e. make calls to and from an Application Server, that serves you 'Smart' data or consume it 'locally' whereby you use the Business Objects right up alongside your Data Access Layer.

Once I'd discovered using Csla with an Application Server, a whole new world opened up. The Application Server works, pretty much based on a base Data Access Layer, that comprises of 'Data Transfer Objects' and Interfaces. This enables you to, kind of 'Future code'. You can build up the Interfaces and D.T.O.'s on speculation of what your actual data will look and behave like, without ever connecting to it. The actual data connections themselves are made by another specific D.A.L. which consumes the base D.A.L. and implements the Interfaces. As your base D.A.L. is just a set of D.T.O.'s and Interfaces, your front end code can make calls to the Application Server purely by referring to your base D.A.L. never needing to know anything about where the data comes from. As well as giving total function seperation, this also enables you to do some pretty nifty stuff.

We know it shouldn't happen, but often, you'll have several sets of the same data spread about your Organisation. Using a Csla.net Application server, you could build 'Ideal' data models which could then populate themselves from the best set of duplicate data. That data could then feed back across the various systems where it lives and update itself accordingly. Once you have made the mapping, you can just let the Application Server do it's work and get on with your job.

I've not even begun to describe what other stuff it can do, but I'd highly recommend have a look at Csla.net. It may look fiendishly complicated at first, but once you get your head round it, it's usefulness out-weighs any complications.