Microsoft Codename Acropolis - Unwrapped
In this post I take a look at Acropolis - what it is and why should developers be concerned about it. Also, I compare it to some offerings on OS X to help clear things up.
# Parts. A part is a reusable, discrete component of business logic. Don’t try and map this to an existing class in an existing app because unless you’re currently doing composite app building using something like the CAB (Composite Application Block, another offering from Microsoft’s Patterns and Practices gurus) you probably don’t have any one object that performs this task. Let’s say you’re building a point of sale application and you have a screen that has a transaction ledger on it. You might (if you’re a good little programmer) encapsulate the business logic required for maintaining a transaction ledger in a Part. This leads us to the next piece of the puzzle: Part Views.
# Part View. A part view is essentially a self-contained class (comprised of both XAML and C#) that is the view of a part. In true and proper Model-View-Controller/Model-View-Presenter fashion, the view is responsible for receiving input from the user and rendering underlying data. It does nothing more than that.
# Services. Unlike what the current buzz around the word “service” indicates, this is not a web service, nor is it a network service or a REST/POX service and it is not a 24-hour service station serving donuts (though, that would be awesome…mmm…donuts….). In the Acropolis (and generic Composite Application Programming terminology), a service is a self-contained piece of loosely coupled code that provides a service to a part or to the entire application. In the financial ledger example, you might have a Service that downloads transactions from the bank. That Service can then feed the transactions to the Part, which will be picked up automatically by bindings in the Part View. Savvy?
Read more, click below.
