I get a lot of questions about the new ADO.NET Entity Framework and LINQ and how these technologies interact with CSLA .NET. I've discussed this in a few other blog posts, but the question recently came up on the CSLA .NET forum and I thought I'd share my answer:

They are totally compatible, but it is important to remember what they are for.

Both ADO.NET EF and LINQ work with entity objects - objects designed primarily as data containers. These technologies are all about making it an easy and intuitive process to get data into and out of databases (or other data stores) into entity objects, and then to reshape those entity objects in memory.

CSLA .NET is all about creating business objects - objects designed primarily around the responsibilities and behaviors defined by a business use case. It is all about making it easy to build use case-derived objects that have business logic, validaiton rules and authorization rules. Additionally, CSLA .NET helps create objects that support a rich range of UI supporting behaviors, such as data binding and n-level undo.

It is equally important to remember what these technologies are not.

ADO.NET EF and LINQ are not well-suited to creating a rich business layer. While it is technically possible to use them in this manner, it is already clear that the process will be very painful for anything but the most trivial of applications. This is because the resulting entity objects are data-centric, and don't easily match up to business use cases - at least not in any way that makes any embedded business logic maintainable or easily reusable.

CSLA .NET is not an object-relational mapping technology. I have very specifically avoided ORM concepts in the framework, in the hopes that someone (like Microsoft) would eventually provide an elegant and productive solution to the problem. Obviously solutions do exist today: raw ADO.NET, , the DAAB, nHibernate, Paul Wilson's ORM mapper, LLBLgen and more. Many people use these various technologies behind CSLA .NET, and that's awesome.

So looking forward, I see a bright future. One where the DataPortal_XYZ methods either directly make use of ADO.NET EF and LINQ, or call a data access layer (DAL) that makes use of those technologies to build and return entity objects.

Either way, you can envision this future where the DP_XYZ methods primarily interact with entity objects, deferring all the actual persistence work off to EF/LINQ code. If Microsoft lives up to the promise with EF and LINQ, this model should seriously reduce the complexity of data access, resulting in more developer productivity - giving us more time to focus on the important stuff: object-oriented design .

I have a custom data source control as part of my CSLA .NET framework. It is somewhat like ObjectDataSource, but works with objects that are created through factory methods rather than default constructors (and some other variations).

All is pretty well with this control, except one issue: it fails when adding a CslaDataSource control to a page as a new data source from a DetailsView or other control.

In other words, you add a DetailsView to the page, then tell that control you want it to bind to a new data source and it brings up a wizard, where you pick CslaDataSource so a new one is added to the page.

The problem I’m getting is a VERY odd exception: Csla.Web.CslaDataSource can not be cast to Csla.Web.CslaDataSource.

Yes, that’s right – the type can’t be cast to itself.

I believe this is because the wizard is loading its own copy of Csla.dll into memory, separate from the one used by the web forms designer. Or something like that. This even confuses the debugger – it can’t show details about the type because it says the type is loaded into two different GUIDs. I don’t know what the GUIDs represent (appdomains, versions?), but it is obviously not good.

This is very weird, and after hours of time on this, I’m quite stumped. Any help, clues, pointers or ideas are VERY welcome!

Thanks! Rocky

It seems that people are always looking for The Next Big Thing™, which isn’t surprising. What I do find surprising is that they always assume that TNBT must somehow destroy the Previous Big Thing™, which in the field of software development was really object-orientation (at least for most people).

Over the past few years Web Services and then their reincarnation as SOA or just SO were going to eliminate the use of OO. As more and more people have actually implemented and consumed services I think it has become abundantly clear that SOA is merely a repackaging of EAI from the 90’s and EDI from before that. Useful, but hardly of the sweeping impact of OO, at least not in the near term.

Though to be fair, OO took more than 20 years before it became remotely “mainstream”, and even today only around 30% of developers (based on my informal, but broad, polling over the past couple years) apply OOD in their daily work. So you could question whether OO is “mainstream” even today, when the vast majority of developers use procedural programming techniques.

Even though the majority of .NET and Java developers don’t actually use OO themselves, both the .NET and Java platforms are OO throughout. So there’s no doubt that OO has had an incredible impact on our industry, and that it has shaped the major platforms and development styles used by almost everyone.

So perhaps in 15-20 years SO really will have the sweeping impact that OO has had on software development. And I’m not sure that would be a bad thing, but it isn’t a near-term concern.

However, I was recently confronted by a (so-called) newcomer: workflow. Yes, now workflow (WF) is going to kill OO, or so I’ve been told. In fact, Through indirect channels, my challenger suggested that the CSLA .NET framework is obsolete going forward because it is based on these “old-school” OO concepts.

Obviously I beg to differ

It is true that some of the concepts I employ in CSLA .NET are quite old, but I am not ready to through OO into the “old-school” bucket just yet... The idea is somewhat ironic however, because WF is being put up as The Next Big Thing™. Depressingly, there's virtually no technology today that isn't a rehash of something from 20 years ago. That's more true of SOA and WF than OO. Remember that SOA is just repacking of message-based architecture, only with XML, and workflow is an extension of procedural design and the use of flowcharts. At least OO can claim to be younger than either of those two root technologies.

Personally, I very much doubt the use of objects as rich behavioral entities will go away any time soon. Sure, for non-interactive tasks procedural technologies like WF might be better than OO (though that's debatable). And certainly for connecting disparate systems you need to use loosely coupled architectures, of which SOA is one (but not the only one).

But the question remains: how do you create rich, interactive GUI applications in a productive and yet maintainable manner?

Putting your logic in a workflow reduces interactivity. Putting your logic behind a set of services reduces both interactivity and performance. Putting your logic in the UI is "VB3 programming". So what's left? For interactive apps you need a business layer that can run as close to the user as possible and using business objects is a particularly good way to do exactly that.

Neither WF nor WCF/SOA are, to me, competitors to CSLA. Rather, I see them as entirely complimentary.

Perhaps ADO.NET EF and/or LINQ are competitors - that depends on what they look like as they stabilize over the next several months. Everything I’ve seen thus far leads me to believe these technologies are complimentary as well. (And Scott Guthrie agrees – check out his recent interview on DNR) Neither of them addresses the issues around support for data binding, or centralization of business logic in a formal business layer.

But when it comes to SOA I still think it is a “fad”. It is either MTS done over with XML - which is what 95% of the people out there are doing with "services", or it is EDI/EAI with XML - which is a good thing and a move forward, but which is too complex and has too much overhead for use in a typical application. I think that most likely in 5-10 years we'll have a new acronym for it – just adding to the EDI/EAI/SOA list.

Just like "outsourcing" became ASP which became SaaS. The idea doesn't die, it just gets renamed so more money can be made by selling the same stuff over again - often to people who really don't need/want it.

The point is, our industry is cyclical. And we're heading toward into a period where "procedural programming" is once again reaching a peak of usage. This time under the names SOA and workflow. But if you step back from the hype and look at it, what's proposed is that we create a bunch of standalone code blocks that exchange formatted data. A set of procedures that exchange parameters. Dress it up how you like, that's what is being proposed by both the SOA and WF crowds.

And there's nothing wrong with that. Procedural design is well understood.

And it could actually work this time around if we don't cheat. I still maintain that the reason procedural programming "failed" was because we cheated and used common blocks and global variables. Why? Because it was too inefficient and required too much code to formally package up all the data and send it as parameters.

If we can stomach the efficiency and coding costs this time around - packing the data into XML messages - then I see no reason why we can't make procedural programming work in many cases. And by naming it something trendy, like SOA and/or workflow, we can avoid the negative backlash that would almost certainly occur if people realized they were abandoning OO to return to procedural programming.

Having spent the first third of my career doing procedural programming, I wouldn't necessarily mind going back. In some ways it really was easier than using objects - though there are some very ugly traps that people will have to rediscover again on this go-round. Most notably the trap that a procedure can't be reused without introducing fragility into the system, not due to syntactic coupling or API changes, but due to semantic coupling (about which I've blogged).

This is true for procedures and any other "reusable" code block like a workflow activity or a service. They all suffer the same limitation - and it is one that neither WSDL nor compilers can help solve...

Anyway, kind of went on a rant here - but I find it amusing that, in some circles at least, OO is viewed as the "legacy" technology in the face of services or workflow, which are even more legacy than OO

Dunn Training has scheduled the next CSLA .NET class for Feb 26-28 in Atlanta. Feedback from the classes thus far has been very positive, for example:

From Dave Boal from Denver, CO:

I need to thank you once again for getting me committed to CSLA. I have always been interested in CSLA, but in the past, never actually made it to the point of applying the technology. I have never took the time required to understand, let alone evaluate the technology. Your course and enthusiasm, combined with chapters 6-8 of Rocky's book, burst me through this evaluation barrier in just 7 days, something I did not think was possible in less than 3 months.

If you want to get a quick, solid, start using CSLA .NET I recommend you consider Dunn Training's class.

The CSLA .NET Version 2.1 Handbook is available NOW at http://store.lhotka.net for both C# and VB.

Additionally, version 2.1.3 of CSLA .NET is now available for download from this location.

Version 2.1.3 includes some bug fixes and minor enhancements. The enhancements are primarily around the CslaDataSource web control, which now provides more integrated support for paging and sorting.

Most importantly, version 2.1.3 is the specific version described in my CSLA .NET Version 2.1 Handbook. I am releasing this as a ~160 page ebook, available in editions for both C# and VB, for purchase directly from my web site.

This new book is best thought of as a sequel to my my Expert C# 2005 Business Objects and Expert VB 2005 Business Objects books. It covers the changes made since CSLA .NET 2.0 was released: how the framework has changed, and how to use the new features and capabilities. Please note that this is not a replacement for those books: it expands on them.

I hope you enjoy CSLA .NET 2.1.3, and the new book. Thank you, code well, have fun!

Thanks to a lot of work by fellow Magenic consultant Chuck Macomber, my CSLA .NET code is now in Subversion (svn) rather than in cvs. Thank you Chuck!!

I'm told that svn offers many advantages over cvs. Just at the moment all I see are the differences where I need to learn and adjust, but that will pass

I've left cvs alive for the moment, but Chuck was able to port all the history into svn, so once things get settled I should be able to entirely drop cvs.

The svn repository is at svn://svn.lhotka.net/csla, and it should be open for anonymous read. As with cvs, I'm allowing anyone to read the contents of the respository.

Also, the web viewer (www.lhotka.net/cslacvs) remains alive, but now defaults to using the svn repository. The cvs repository is still visible there too, just use the drop-down in the upper right-hand corner of the page to switch to it. One known issue at this time, is that the diff function doesn't work in svn. I don't know why, but python seems unable to find the diff program under svn, though it works fine under cvs.

If you have any idea how to solve this diff issue, I'm all ears. Google, thus far, has been of little value... (I am now guessing the diff issue was a caching problem, because it simply started working all by itself... Gotta love web development...)

Going forward, all changes to CSLA .NET will occur in the svn repository.

Version 2.1.2 of CSLA .NET is now available for download from this location.

Version 2.1.2 includes some bug fixes and minor enhancements. The enhancements are primarily around the CslaDataSource web control, which now provides more integrated support for paging and sorting.

Most importantly, version 2.1.2 is the specific version described in my CSLA .NET Version 2.1 Handbook. I am releasing this as a ~160 page ebook, available in editions for both C# and VB, for purchase directly from my web site.

The VB CSLA .NET Version 2.1 Handbook is available NOW at http://store.lhotka.net.

Look for the C# edition in the very near future (it is in the final review stage).

This new book is best thought of as a sequel to my Expert C# 2005 Business Objects and Expert VB 2005 Business Objects books. It covers the changes made since CSLA .NET 2.0 was released: how the framework has changed, and how to use the new features and capabilities. Please note that this is not a replacement for those books: it expands on them.

Releasing this as an ebook in PDF format is a risk on my part. I put just as much time and effort into writing this book as I have any other book I've written, but I want to provide a more cost-effective way for you to purchase this material than through normal publishing channels. It is my sincere hope that you will purchase this book if you read it (even after a few people have purchased it and they start sharing it for free).

I'm not giving up on traditional publishing channels necessarily. I'll most likely use a traditional publishing approach when I reach a point that CSLA .NET and/or my thinking changes to such a degree that there'd be value for you, as a reader, in me rewriting my books in a major way. But when I'm writing about extra functionality that rests on the existing work, it seems like I'm providing better value to you by selling a lower-cost sequel than forcing you to repurchase much of the same material to get at the new parts.

But all this hinges on people's honesty. On your honesty.

I hope you enjoy CSLA .NET 2.1.2, and the new book. Thank you, code well, have fun!

There's this "five things about me" tagging meme going around, and I've now been tagged by Bill, Craig and Andrea.

1. I grew up in the middle of Minnesota, surrounded by hundreds of acres of forest and lakes. Our nearest neighbor was a mile away. The nearest town 14 miles away, and the nearest real town over 30 miles away. The nearest city: a 2.5 hour drive. As a youth, I lived one of those lives of adventure you might read about from long in the past. I spent my time fishing, hunting, trapping, snowmobiling, boating, swimming and generally wandering through the woods and lakes of central Minnesota.

2. I love alternative metal and alternative rock. Rush, Queensryche, Godsmack, Linkin Park and so forth. Good rock, to me, requires thought-provoking lyrics, evocative sound and serious riffs!

3. I love speculative fiction (the fancy name for science fiction and fantasy). Tolkien, Asimov, Niven, Reynolds, Scalzi, McKillip, Norton and many others are on my favorites list. Between all these books, and my wife's collection of all the essays, letters and other writings of America's founding fathers (plus many random other books on many topics) we have an entire room set aside as a library.

4. My first overseas trip was to London, to attend a Babylon 5 convention to commemorate the conclusion of the show. My wife was (and technically still is) a moderator on the Babylon 5 moderated newsgroup (remember usenet? ).

5. I'm a would-be game developer. Years ago I wrote a MUD for the DEC VAX called Mordecai. It consumed all the resources the university VAX could muster back then, and I even ended up working with the Operations guys to build in capabilities to throttle the game so it wouldn't be playable during prime homework usage periods and that sort of thing. I've written bits and pieces of a much more ambitious .NET equivalent, but that project stalled a while back. The reality today is that game development is such a small part of building a game in total (graphics, physics engines and so forth are a much bigger part) that it is hard to get as excited about this stuff as I used to be...

Kindly enough, and because I don't have time to track down who's been tagged or not, I'm not tagging anyone, so this thread of execution ends here

I recently had an email discussion where I was describing why I needed to solve the problem I described in this article for WPF and this article for Windows Forms.

In both cases the issue is that data binding doesn’t refresh the value from the data source after it updates the data source from the UI. This means that any changes to the value that occur in the property set code aren’t reflected in the UI.

The question he posed to me was whether it was a good idea to have a property set block actually change the value. In most programming models, goes the thought, assigning a property to a value can’t result in that property value changing. So any changes to the value that occur in the set block of a property are counter-intuitive, and so you simply shouldn’t change the value in the setter code.

Here’s my response:

The idea of a setter (which is really just a mutator method by another name) changing a value doesn't (or shouldn't) seem counter-intuitive at all.

If we were talking about assigning a value to a public field I’d agree entirely. But we are not. Instead we’re talking about assigning a value to a property, and that’s very different.

If all we wanted were public fields, we wouldn't need the concept of "property" at all. The concept of "property" is merely a formalization of the following:

1. public fields are bad
2. private fields are exposed through an accessor method
3. private fields are changed through a mutator method
4. creating and using accessor/mutator methods is awkward without a standard mechanism

So the concept of "property" exists to standardize and formalize the idea that we need controlled access to private fields, and a standard way to change their value through a mutator method.

Consider the business rule that says a document id must follow a certain form - like SOP433. The first three characters must be alpha and upper case, the last three must be numeric. This is an incredibly common scenario for document, product, customer and other user-entered id values.

Only a poor UI would force the user to actually enter upper case values. The user should be able to type what they want, and the software will fix it.

But putting the upper case rule in the UI is bad, because code in the UI isn't reusable, and tends to become obsolete very rapidly as technology and/or the UI design changes. There's nothing more expensive over the life of an application than a line of code in the UI. So while it is possible to implement this rule in a validation control, in JavaScript, in a button click event handler - none of those are good solutions to the real problem.

Yet if that rule is placed purely in the backend system, then the user can't get any sort of interactive response. The form must be "posted" or "transmitted" to the backend before the processing can occur. Users want to immediately see the value be upper case or they get nervous.

So then we're stuck. Many people implement the rule twice. Once in the UI to make the user happy, and once in the backend, which is the real rule implementation. And then they try to keep those rules in sync forever - the result being an expensive, unreliable and hard to maintain system.

I've watched this cycle occur for 20 years now, and it is the same time after time. And it sucks.

This, right here, is why VB got such a bad name through the 1990’s. The VB forms designer made it way too easy to write all the logic in the UI, and without any other clear alternative that's what happened. The resulting applications are very fragile and are impossible to upgrade to the next technology (like .NET). Today, as we talk, many thousands of lines of code are being written in Windows Forms and Web Forms in exactly the same way. Those poor people will have a hell of a time upgrading to WPF, because none of their code is reusable.

What's needed is one location for this rule. Business objects offer a workable solution here. If the object implements the rule, and the object runs on the client workstation, then (without code in the UI) the user gets immediate response and the rule is satisfied. And the rule is reusable, because the object is reusable - in a way that UI code never can be (or at least never has been).

That same object, with that same interactive rule, can be used behind Windows Forms, Web Forms, WPF and even a web services interface. The rule is always applied, because it is right there in the object. And for interactive UIs it is immediate, because it is in the field's mutator method (the property setter).

So in my mind the idea of changing a value in a setter isn't counter-intuitive at all - it is the obvious design purpose behind the property setter (mutator). Any other alternative is really just a ridiculously complex way of implementing public fields. And worse, it leaves us where we've been for 20+ years, with duplicate code and expensive, unreliable software.