.NET

CSLA.NET Study Group - Week 2

Roy Ogborn — Fri, 01 Oct 2004 01:35:00 GMT

This week's CSLA study group sessions went nicely (see earlier post). I started off with a white-boarding session describing distributed objects and the trade-offs that must be considered before deciding when to split logical layers into physical tiers. We discussed network latency, “chunky“ vs. “chatty“ interfaces, how to turn a “chatty“ object interface into something more “chunky“ using a UI layer inside of a web service ... things like that.

Now Rockford has a great knack for explaining how things work in his books and that's a great talent. But I managed to take things down a step lower (or three) by explaining, not how, but why object serialization must occur. If objects could travel through a CAT5 Ethernet cable intact, the cable would have to expand with a lump much like you could imagine a large Anaconda who has just eaten an Ostrich. You can picture that lump slowly moving down the length of its body (not to mention feathers everywhere).

The plastic jacket that covers the actual wire inside a CAT5 cable is, actually, quite stretchy, so, in fact, business objects could indeed travel across the wire without requiring serialization. The problem is that some of our objects are quite large, and the lumps going through the wire would be quite like our now satisfied Anaconda friend. The difference being that our object lumps travel much, much faster.

The reason why Microsoft decided to create mechanisms to serialize objects into streams of teeny-tiny ones and zeros is because their lawyers (who are very smart) advised them against creating these object lumps. Plasterboard, the stuff that makes up much of the walls in our homes and offices is, as you know, very brittle. When big object lumps start flying down those wires at nearly the speed of light, the damage caused, and potential loss of life, from our walls exploding from the pressure of the expanding wires within, would bring lawsuits that would take the firm to its knees.

And so, the SOAP protocol was invented along with Binary Serialization so that our traveling, distributed, business objects wouldn't wreak havoc on known civilization.

OK, I jest. CAT5 cable does not expand, so objects can't really travel over the wire unless they're serialized first.

We made it through that discussion, and a discussion about UI in Charge, Class in Charge, Object in Charge ... though I think this last “in Charge“ topic is one we're going to have to revisit so all are quite clear on the differences. Some individuals in this group are very new to OO programming.

Next week, we shall continue on our journey through CSLA architecture concepts. I get to kick the week off with a discussion of Relational vs. Object Modeling; ERD's vs. Static Structure Diagrams and Object to Relational mapping.

I love this stuff!

Roy

CSLA.NET Study Group - Week 1

Roy Ogborn — Fri, 24 Sep 2004 23:49:00 GMT

The group decided to meet two days a week for two hours starting at 8 AM. This schedule is working quite well. Ninety minutes per session would have been a bit too short to complete the interesting discussions that are coming up. There are about six individuals in our group plus myself (I'm the facilitator). Before our first meeting, I asked the group to read 8 pages from Chapter 1 of Expert C# Business Objects: Distributed Architecture; p. 1 Logical and Physical Architecture; pp. 2-3

CSLA.NET Study Group

Roy Ogborn — Thu, 16 Sep 2004 21:39:00 GMT

Next week I begin facilitating a study group consisting of C# .NET software developers. We'll be focusing on Rockford Lhotka's CSLA.NET application framework for C#. I plan on tracking the progress of the group here, posting how we wind up organizing and distributing tasks, how well folks are participating, and our overall progress.

My intention is to have this team of software developers (who are employed by the same firm) be more productive when building custom business software by using a common application framework for each application they design.

Case in point: I've used Lhotka's pre-.NET version of CSLA on several large web applications. One of them is in use at Qwest (at least it was when I last looked) by nearly 2000 Qwest employees. Qwest was pleasantly surprised at how quickly and how bug-free I created this custom work-flow system for them. It was the underlying CSLA application framework that helped produce the great results. [That system also used what I consider to be the precursor to ASP.NET, which was VB6's webclasses, aka "IIS Application", but that's another story.]

For a multi-person team, the benefits of using a standard application framework are even greater. When everyone on the team is building different applications using whatever method each chooses, there's a huge ramp-up time for anyone joining the project. Plus the folks who later have to maintain the software systems will have no clue how any particular application works inside. When a common framework is used for every new application built, this situation improves drastically.

So stay tuned ... You'll get to follow our progress (if you so desire). Hey, and if you have any constructive comments based on your experiences, please drop me a note!

Roy