csa:Quote from Juvals class: "For the beginner architect, there are many options. For the Master architect, there are only a few."
Which must end with "... And the Master knows that no one architecture solves all problems."
Juval is exactly right. While it might seem like a lot of options are valid, in reality only a few actually work in practice. Unfortunately you often can't know which will fail until you are months into a project.
At the same time, no one architecture is always right. And for larger or complex applications no one architecture will solve all problems within the context of the application!!
(For small to mid-size applications of average complexity that's not true btw. In many cases one architecture works just fine - assuming it is the right one )
If you have a large/complex application, you will (at a minimum) need an architecture for the OLTP portions of the application and an architecture for the back-office processing portions of the application. Odds are you'll also need an architecture for enterprise application integration (EAI - often now called SOA because SOA is the current fad for addressing this area).
CSLA .NET is particularly good at the OLTP portions of applications, and it plays reasonably well in the back-office areas (when combined with workflow/queued processing). It plays in the EAI space in a limited capacity, by providing an easy way to build your services.
A pure service-oriented architecture is almost the reverse. That kind of architecture plays very nicely in the EAI space, and reasonably well in the back-office areas (when combined with workflow/queued processing). But service-oriented architectures don't play particularly well in the OLTP space, at least if user interactivity is considered valuable (in other words when you use Windows Forms, WPF or Silverlight).
Personally, I assume that any large/complex application should start by looking at both CSLA .NET and a service-oriented approach. The two are very complimentary, and when combined with a bit of workflow/queued processing they provide a pretty complete solution.
But I wouldn't try to implement the OLTP portions of an app in SOA, nor would I try to implement the EAI portions in pure CSLA, because that would be misusing each architecture in the areas where they are weakest.
I should also note that Juval and I are good friends. We also have the most wonderful discussions on architecture every time we get together. At the start of every discussion we appear to disagree (even to each other), and after a couple hours we end up realizing we were saying the same thing, but we started from different beginning positions...
I start with objects and OLTP. Juval tends to start with remote procedure calls and/or services and back-office processing. But the two always meet, and they are always necessary to build any large/complex system.
Copyright (c) Marimer LLC