What Acropolis Is and Isn’t
Posted by Keith Elder | Posted in .Net, Programming, Smart Clients | Posted on 08-06-2007
Ayende wrote a post about Acropolis as another executable XML language. Then a few other people chimed in on comments about Acropolis being another example of Microsoft providing tools to turn bad developers into mediocre developers. I think the point of Acropolis has been totally lost in this conversation so please allow me to weigh in.
To start with WPF is already expressed in XML. This has been known for awhile and we’ve all seen amazing results of expressing the UI declaratively. Look at all the eye candy WPF and Silverlight has dazzled us with over the past several months as an example. Acropolis is simply leveraging the new WPF stack so to call it an executable XML language is a little far fetched. Of course it is true that XAML generated to display WPF applications is in XML format but it isn’t a language it is merely parsed. Calling Acropolis an executable XML language is like calling a component or control that ships out the box with the framework a language because that is what Acropolis is, additional controls that are going to be shipping to enhance WPF which in return will help us composite our client applications better.
Acropolis isn’t a language but merely an extension of controls and patterns to WPF similar to the Smart Client Software Factory and CAB built leveraging the richness of Windows Presentation Foundation. That is the Forrest Gump definition of how I would explain it.
We’ve already seen and tried to solve a lot of the problems developers face in building rich client applications with SCSF and CAB. Acropolis is no different in what it is trying to solve just in how it is put together. Meaning Acropolis is built on the WPF stack rather than built on object oriented design patterns. Under the hood there are design patterns going on I am sure but they are abstracted to controls.
To give you an analogy here is how I would think about it. To me it is no different than Asp.Net 2.0 shipping the Login controls. This is an example of a common problem web developers face and an abstract way of dealing with that problem. Acropolis to me is no different in the fact that there are inherent things as client developers we have to do each and every time we start a client application. Acropolis will hopefully help us solve these problems, but it isn’t a new XML language. It also has nothing to do making bad developers mediocre developers as one commenter pointed out. Just as the login control bundled with Asp.Net 2.0 didn’t make bad developers mediocre developers.
The point of Acropolis is to take things that are “common” that client developers have to do and abstract the repetitiveness of building composite applications into something that can be reused in the framework. As Brad Abrams pointed out in his comment there is still separation of code and business logic.
I saw at lengthy talk on Acropolis at TechEd done by Kathy Kam and mostly what I saw was a set of new controls that will assist client developers in building out the plumbing of smart client applications faster. It is still new but the direction it is going will in my opinion solve what it is trying to solve if done correctly.