Building on the vision of software + services, Microsoft Code Name “Acropolis” makes it easier to build and manage modular, business-focused, client applications for Microsoft Windows on the .NET Framework. It builds on the rich capabilities of Windows and the .NET Framework, including Windows Presentation Foundation (WPF), by providing tools and pre-built components that help developers quickly assemble an application from loosely-coupled parts and services. Code Name “Acropolis” reduces the complexities of building occasionally connected client applications and provides the ability to assemble and reconfigure systems without having to write a lot of code. Code Name “Acropolis” is part of the .NET Client Futures release, Microsoft’s preview of upcoming technologies in Windows client development.

For more information about Code Name “Acropolis” and the .NET Client Futures, see Windowsclient.net.

References:

http://www.rollthunder.com/Newsletter/newslv9n1.htm
http://blogs.msdn.com/ashish/archive/2007/06/07/wpf-cab-has-arrived.aspx
http://blogs.msdn.com/gblock/archive/2007/06/06/acropolis-the-future-of-smart-client.aspx

Pasted from <http://ameleta.spaces.live.com/blog/cns!5F6316345A821420!163.entry>

MVP vs MVC

Model View Presenter vs Model View Controller

Intro

In my work I often deal with the situation when people use MVС/MVP patters without clear understanding the really difference between them. In this article I will try to explain my view on the issue.

It’s important to understand that in n-tier systems MVP/C patterns are responsible for the presentation layer only. It’s not about how you build data or services layers, it’s about separating the data (model) and the user interface(view), telling you how the user interface communicates with data. Using these patterns gives your application independence on changing presentation without depending on data and controlling logic.

Generally:

1.       Model means data & business logic model. It’s not always a DataSet, DataTable or such stuff. It’s kind of components or classes which can provide data and can receive the data to store it somewhere else. To simplify understanding of Model just think about it as “Façade” class.

2.       View represents data for the user. Generally it’s just the UI, and not always UI logic. For example in ASP.NET the page with controls is View.  The View can receive data directly from Model, but View never updates Model.

3.       The Presenter/Controller contains the logic to update Model regarding the user’s actions into the View. View only notifies Controller about user’s actions. Controller extracts data from View and sends it to Model.

The main point of the MVC/P pattern is to split Model from View/Controller to make Model independent from them. So, Model cannot contain the references to the V/C.

What is the MVC (model-view-controller)?

1.       Controller initializes the events of View interface to interact with model and controller.

2.       The user interacts with View (UI).

3.       Controller handles user’s events (can be the “observer” pattern) and asks Model to update.

4.       Model raises events, informing subscribers (View) about changes.

5.       View (UI) (subscribes to model events) handles Model’s evens and shows new Model’s data.

6.       The User Interface waits for the further user actions.

Primary points are:

1.       View does not use Controller to update Model. Controller handles the events from View to manage user’s interaction and data (via interaction with Model)

2.       Controller can be combined with the View. It’s what the Visual Studio do for the Windows Forms by default. The primary point is logical separation of Model from the View.

3.       The Controller do not contains the rendering logic.

The example below illustrates the “Active-MVC” pattern, also known as “the original MVC pattern”.

There is also the “Passive-MVC” pattern.

The differences are that:

-         Model knows nothing about Controller and View, it only used by them both.

-         Controller uses View asking it to render new data.

-         View uses Model to get the data only when Controller ask View about it (no subscription between View and Model).

-         Controller handle Model data changes.

-         Controller may contain the rendering logic for the View.

And now we are close to MVP pattern.

MVP is like an MVC, but View doesn’t use Model.

In the MVP View and Model are utterly separated from each other using the Presenter. Any interaction between View and Model take place in Presenter.

Presenter is like the Controller, but which:

1.       handles the user events from View (in MVC View handles this events);

2.       updates Model using updated data from View (MVC passive just informs View to get/set new data from Model and MVC active takes no role in it, because Model informs View);

3.       examines Model for changes (like the MVC passive);

4.       (the main difference from MVC) gets Model data and stores them into View;

5.       (the main difference from MVC active) notifies View about updates;

6.       (difference from MVC) renders View using the Presenter

So, MVP has following pros:

1.       Model is separated from View and we can change View independently from Model

2.       We using Model more effective, because all interactions are now in one place –in the Presenter(Controller)

3.       We can use one Presenter(Controller) for many Views without changing the Presenter(Controller) logic, it’s can be useful because View changes more often than the Presenter(Controller)

4.       If we are storing View logic in the Presenter(Controller) we can test the logic independent of user interaction (Unit Testing)

But there are cons:

1.       Too many interactions between View and Presenter because rendering View data is in the Presenter;

Also you need to understand that if you render too much data for View you are tied up on the particular View. So if  View needs to be changed you need to update the Presenter either, For example, if you rendered html and need to render the pdf, there is a big possibility that View need to be changed too.

Pasted from <http://blogs.infragistics.com/blogs/tsnyder/archive/2007/10/17/mvc-or-mvp-pattern-whats-the-difference.aspx>

Over the years I have mentored many developers on using design patterns and best practices. One question that keeps coming up over and over again is: What are the differences between the Model View Controller (MVC) and Model View Presenter (MVP) patterns? Surprisingly the answer is more complex than what you would suspect. Part of reasons I think many developers shy away from using either pattern is the confusion over the differences.

Before we dig into the differences let’s examine how the patterns work and the key benefits to using either one. Both (MVC & MVP) patterns have been use for several years and address a key OO principal namely separation of concerns between the UI and the business layers. There are a number of frameworks is use today that based on these patterns including: JAVA Struts, ROR, Microsoft Smart Client Software Factory (CAB), Microsoft Web Client Software Factory, and the recently announced ASP.Net MVC framework.

Model View Controller (MVC) Pattern

The MVC pattern is a UI presentation pattern that focuses on separating the UI (View) from its business layer (Model). The pattern separates responsibilities across three components: the view is responsible for rending UI elements, the controller is responsible for responding to UI actions, and the model is responsible for business behaviors and state management. In most implementation all three components can directly interact with each other and in some implementations the controller is responsible for determining which view to display (Front Controller Pattern),

Model View Presenter (MVP) Pattern

The MVP pattern is a UI presentation pattern based on the concepts of the MVC pattern. The pattern separates responsibilities across four components: the view is responsible for rending UI elements, the view interface is used to loosely couple the presenter from its view, the presenter is responsible for interacting between the view/model, and the model is responsible for business behaviors and state management. In some implementations the presenter interacts with a service (controller) layer to retrieve/persist the model. The view interface and service layer are commonly used to make writing unit tests for the presenter and the model easier.

Key Benefits

Before using any pattern a developers needs to consider the pros and cons of using it. There are a number of key benefits to using either the MVC or MVP pattern (See list below). But, there also a few draw backs to consider. The biggest drawbacks are additional complexity and learning curve. While the patterns may not be appropriate for simple solutions; advance solutions can greatly benefit from using the pattern. I’m my experience a have seen a few solutions eliminate a large amount of complexity but being re-factored to use either pattern.

Loose coupling – The presenter/controller are an intermediary between the UI code and the model. This allows the view and the model to evolve independently of each other.

Clear separation of concerns/responsibility

UI (Form or Page) – Responsible for rending UI elements

Presenter/controller – Responsible for reacting to UI events and interacts with the model

Model – Responsible for business behaviors and state management

Test Driven – By isolating each major component (UI, Presenter/controller, and model) it is easier to write unit tests. This is especially true when using the MVP pattern which only interacts with the view using an interface.

Code Reuse – By using a separation of concerns/responsible design approach you will increase code reuse. This is especially true when using a full blown domain model and keeping all the business/state management logic where it belongs.

Hide Data Access – Using these patterns forces you to put the data access code where it belongs in a data access layer. There a number of other patterns that typical works with the MVP/MVC pattern for data access. Two of the most common ones are repository and unit of work. (See Martin Fowler – Patterns of Enterprise Application Architecture for more details)

Flexibility/Adaptable – By isolating most of your code into the presenter/controller and model components your code base is more adaptable to change. For example consider how much UI and data access technologies have changed over the years and the number of choices we have available today. A properly design solution using MVC or MVP can support multi UI and data access technologies at the same time.

Key Differences

So what really are the differences between the MVC and MVP pattern. Actually there are not a whole lot of differences between them. Both patterns focus on separating responsibility across multi components and promote loosely coupling the UI (View) from the business layer (Model). The major differences are how the pattern is implemented and in some advanced scenarios you need both presenters and controllers.

Here are the key differences between the patterns:

MVP Pattern

View is more loosely coupled to the model. The presenter is responsible for binding the model to the view.

Easier to unit test because interaction with the view is through an interface

Usually view to presenter map one to one. Complex views may have multi presenters.

MVC Pattern

Controller are based on behaviors and can be shared across views

Can be responsible for determining which view to display (Front Controller Pattern)

Hopefully you found this post interesting and it helped clarify the differences between the MVC and MVP pattern. If not, do not be discouraged patterns are powerful tools that can be hard to use sometimes. One thing to remember is that a pattern is a blue print and not an out of the box solutions. Developers should use them as a guide and modify the implementation according to their problem domain.

The information below was extracted from the write-up by Francis K. Cheung.

What are modular, composible applications?

Imagine that you want to need to build an application that, due to its size and complexity, needs to be split up and developed by several teams. Let’s say you have several teams developing modules that can be assembled at run time. There will also be a team in charge of the shared infrastructure. You also need a way for the UI elements from each module to be brought together into a reasonable composite. You also want the modules to be loosely coupled from eachother (no static references). You also want a way for these modules to communicate with eachother. Since there are no static references, you can’t take advantage of standard .NET eventing. You also want to expose services and share them across modules.

This scenario was first addressed by the Composite UI Application Block (CAB) and the Smart Client Software Factory. This scenario was then addressed for Windows Mobile 5: Mobile Client Software Factory. For the composible applications in the web space, the Web Client Software Factory was developed.

The demand for CAB functionality interoperable with WPF’s look and feel prompted the community project WPF CAB.

The Composite Application Guidance for WPF can help you split the development of your WPF client application across multiple development teams, each responsible for the development of a piece of the application, and help you seamlessly compose those pieces together into a client application.

I have done some search on choosing between SCSF (Smart Client Software Factory) and Composite WPF. If using SCSF, you are still able to host WPF SmartParts and develop WPF controls. If you are an existing CAB/SCSF developers, download the reference document at here. The following information was pasted from here:

#1: What should I use when starting a new project?

My personal conclusion: For me that question is obvious: use Composite WPF guidance and WPF if your client-hardware is sufficient for WPF.

WPF adds a lot value that make things for development of enterprise line-of-business client apps much easier - although the design time experience isn’t where it should be, today. And Composite WPF brings you the framework for building extensible and manageable enterprise-level smart clients with WPF! So just use it!

#2: Should you migrate to Composite WPF from CAB/SCSF?

Of course many customers are asking this question right now. They are afraid that they are using an old technology which is not going to be state-of-the-art anymore and running into panic-mode.

Well, I don’t see it that critical. CAB/SCSF is still driven forward by the community (see SCSFContrib, SCSFWPF etc.) and there are lots of people out there answering questions, sharing experience etc. Furthermore according to the Microsoft homepage it is still supported the same way it was supported all the time: it is simply treated as custom code in support cases with Microsoft.

My personal conclusion therefore: if you do not get additional business value out of Composite WPF and if you are happy with CAB/SCSF in your solution, why should you take the effort of migrating to it!? Then you don’t need to… some good reasons to migrate might be:

• native WPF implementation that leverages the base classes of WPF such as its existing command mechanisms etc.
• more lightweight - Composite WPF is more lightweight than CAB/SCSF and I had the feeling that it is easier to learn…
• extended flexibility of Composite WPF: you have the choice which features you want to use and which you don’t want to. Composite WPF features are independent from others - e.g. you could use the MVP/MVC implementation without being bound to any “Controller” or “WorkItem” base classes or to the dependency injection mechanisms.
• the new Unity framework as an easier-to-use, more lightweight dependency injection framework
• the ability of Composite WPF to use another dependency injection framework such as spring etc.

But these are just some thoughts that went through my head. And again - for me important is that if you don’t get any value for YOU out of these advantages then why migrate!? There is no reason for doing so. If you get additional value, then let’s go;)

#3: How do components from CAB/SCSF map to Composite WPF?

As far as I have seen, the Composite WPF framework achieves exactly the same goals as CAB on it’s own. There is no replacement for SCSF available, so far, and according to Microsoft none is planned for the foreseeable future. The team is in a kind-of gathering customer feedback loop right now;) Okay, but let’s map some features from CAB/SCSF to Composite WPF - I assume that you read my paper on CAB/SCSF to fully understand the following table…

As you can see, Composite WPF supports all scenarios but leaves you more “freedom” of whether you want to implement a scenario or not. And also if you implement a scenario you often don’t need to inherit from any base class or apply attributes in most cases. That means you can build-up your own hierarchies without running into too many dependencies of the Composite WPF guidance.

#4: The very basic steps to get from CAB/SCSF to Prism

These are some of the first steps I had to complete while migrating the shell and modules from CAB/SCSF to prism. Essentially these where the following:

1. Create a new solution for the Composite WPF version of my demo.
2. Import the interface libraries from the CAB/SCSF solution to the Composite WPF solution and remove all namespace-, attribute- and base-class references to CAB/SCSF-related classes.
3. Re-create the shell as described in the guidance: I have to admit I didn’t even try to migrate the shell because many of the concepts are different. But I left my IShellExtensionService interface concept and therefore I was able to hide this pretty heavy change from the modules I migrated later on.
4. Add a new class library with some of my own base classes:
   (1) A Controller base class with a state-bag to replace WorkItems. This is a simple as possible and I just used it because I used the WorkItem.State property. (2) A presenter base class with a reference to the original work item.
5. Add the first CAB/SCSF module to my new solution.
6. Replace the “ModuleInit” class by a IModule implementation. I even left the ModuleController-concept for simplicity.
7. Remove the WorkItemController base class reference in my ModuleController class and replace it by the Controller-base class I created in step 4.1 above.
8. Replace CAB-Commands [CommandHandler] by DelegateCommands as used in WPF and WPF composite guidance.
9. Replace all WorkItem.Service usages against a Unity Container Service usage.
10. UI Extension Site usage must be replaced by my IShellExtensionService concepts as described in my paper as they are not available anymore. Or you create your own IShellService that supports extension of menus etc. in your shell.
11. Uncomment CAB/SCSF generated code in the code-besides of the smart parts.
12. Remove all attributes in Presenter classes and SmartParts which are specific to CAB/SCSF.
13. Replace all WorkItem classes with your own, custom Controller classes that inherit from the Controller-base class I’ve created in step 4.
14. Update the configuration and run the application