I recently posted on some important differences between DevForce and RIA Services. Someone posted a comment to the effect that DevForce and CSLA seem to be the same and invited me to comment.
I see the similarities between DevForce and RIA Services. I don’t think DevForce and CSLA are alike at all. Why would someone suggest that they are?
That got me thinking and lead to this post which reframes the question.
It first establishes what we have in common … and how to decide quickly if you should consider any of us … or none of us … for your application project.
Then it articulates fundamental criteria for comparing the three.
Important: These criteria are not evaluative. They are as neutral as I can make them. I feel pretty confident in that neutrality because, as I apply them to the three products, I can not tell which one of them is “better”. They help me organize my thoughts, not decide which one is “right.”
Let's start with the what we have in common.
DevForce, CSLA, and RIA Services target the same problem: building distributed business applications from end to end, server to client.
If you don't think you have this problem, none of us are right for you.
We offer .NET-only products. RIA Services is limited today to Silverlight applications; DevForce and CSLA support most .NET client technologies (I don't think any of us are ready for WP7 .. yet. CSLA may work on the CE; we do not). Your required server and client operating environments may make the choice for you.
We all have the same presumption of a relational database as the primary backing store. Sure we can also persist to other backing stores. But these alternatives appear in supporting roles if they appear at all. None of us are your best choice for building applications that primarily access data through messaging services or persist to one of the NoSql schema-less data stores.
We all attempt to solve your application problem within some flavor of "mobile business objects" paradigm. If you summarily reject a "mobile business object" solution on principle, none of us are right for you.
Finally, we are all framework products. We're not application generators. If you want to drag-and-drop your way to a finished product, we're not for you. If you reject 3rd party frameworks, we are not right for you either.
With me still? Because now we are ready to differentiate the three products.
You have looked at the problem and you've chosen to solve it by allocating some responsibilities to a framework, reserving others for yourself in the expectation that you will be writing custom application code.
Every framework is opinionated. Each says:
- We will be responsible for these tasks (the A-list).
- You will write custom code for these other tasks (the B-list).
- Our architecture and recommend development practices pretty much prescribe that you will write your custom code in manner C.
You look at these opinions and ask yourself
- Do I want the framework to do the things on the A-list?
- Do I want to write code for the things on the B-list?
- Do I want to develop in manner C?
- How productive will I be if I adopt this framework? How quickly can I write quality B-list code when I adopt manner C?
- What items on the A-list do I really have to do myself? Can I take these particular tasks away from the framework with acceptable ease and still, in the main, be using the framework the way it was intended?
- I wish some of the items on the B-list were handled by the framework. What will it take for me to write them myself or acquire them from someone else?
- I don't care about some of the items on the A-list; do these items get in my way and if so, will that be a serious problem?
- Do we have the skills and development culture to use this framework effectively? If not, can we and should we acquire those skills?
- How do these factors collectively influence my development timeline? Do I have a deadline? If so can I reasonably expect to hit the deadline with the resources I have using this framework?
You will also consider some “non-functional” factors
- Product quality and maturity
- Access to source code
- Influence on roadmap and repairs
- Product release schedule
- Community (resources, training, etc.)
- Company stability
I have conspicuously omitted one factor: license costs. CSLA and RIA Services have no license costs. DevForce does. Why doesn’t that matter?
It doesn’t matter because you’re building a custom application that you’ll be living with for years. A few thousand dollars of licensing fees are irrelevant … they are rounding error … compared to the application investment you’re about to make and the risks you are about to assume.
If this is not blindingly obvious to you, you shouldn’t be making this decision. You simply don’t have the requisite business acumen to make the right choice.
When you dissect the products according to these criteria – which you’ve refined and weighted to suit your business environment and requirements – the differences among CSLA, DevForce, and RIA Services will stand out in sharp relief. You will have a foundation for choosing among them.
I said the differences will be stark; I didn’t say that the choice will be easy. Even within the same organization people will weigh some differences more heavily than others.
You will at least have arranged matters so you can see more clearly what you’re arguing about.