M-V-VM Reference Application

Source code checked in, #70298

Project Collection Service Accounts — Mon, 01 Oct 2012 21:36:45 GMT

Upgrade: New Version of LabDefaultTemplate.xaml. To upgrade your build definitions, please visit the following link: http://go.microsoft.com/fwlink/?LinkId=254563

Source code checked in, #70297

Project Collection Service Accounts — Mon, 01 Oct 2012 21:31:58 GMT

Checked in by server upgrade

Source code checked in, #48188

_TFSSERVICE — Thu, 08 Jul 2010 20:15:13 GMT

Checked in by server upgrade

New Post: What should we build?

emi_oasis — Mon, 21 Sep 2009 04:54:56 GMT

I like the idea of the SCRUM management tool.

Another Idea: A personal health record client based on either MS HealthVault or Google Health.

New Post: What should we build?

MichaelLPerry1971 — Sun, 09 Aug 2009 23:47:37 GMT

Things seem kinda quiet here.

*tumbleweed*

I just did a writeup on a blog editor sample app: MVVM and Linq to SQL the easy way. It's in the spirit of Windows Live Writer. Maybe this would be a better reference application than a recipe DB, because we can use standard blog APIs for the client/server demonstration:

Blogger API
Wordpress API
MetaWeblog API
Atom Publishing Protocol

Since anyone can set up a blog, we don't need to fake out the C/S communication. Thoughts?

New Post: Online Recipe Database Webservice

mbrownbh — Mon, 27 Jul 2009 21:20:20 GMT

Just found this in a search...http://www.bigoven.com/recipe-api-interest.aspx

I submitted their form to find out more info. Hopefully something pops up soon.

New Post: Home Kitchen Management Use Cases

MichaelLPerry1971 — Wed, 10 Jun 2009 13:36:09 GMT

I realize that we are building a reference application, and many of these use cases will be pared back or dropped altogether. But here's a list of use cases that (I think) covers the whole problem space:

Enter a recipe
Import a recipe from a file/URL (REML, MealMaster, etc.)
- Search the web for a recipe
- Import from email
- Load file
Export a recipe to a file/service
- Send email
- Post to a forum
- Save to a file
Display a recipe
- Scale ingredients
- Display nutrition information
- Preview
- Print
Take pantry inventory
Search for a recipe
- By inventory
- By ingredient
- By name
- Cross reference results with inventory
- Show nutrition information in results
Create a meal plan
Generate a shopping list
Update inventory from shopping list (after shopping)
- Check items on shopping list that were purchased
- Add items not on shopping list
- Edit items purchased in different quantities
Update inventory from recipe (after cooking)

New Post: Patterns

Billkrat — Tue, 26 May 2009 23:27:44 GMT

[mbrownbh] I've never seen an instance where PM and MVP are used together.

For the record - the PM/MVP is not my design :) It was written by the Prism P&P Team. Back when I was just learning the CompositeWPF Prism I downloaded PrismV2 - Drop 7 (specifically the QuickStarts \ Visual composition \ TopDown \ TopDownUIComposition solution) and adopted the patterns I've been describing. I built entire frameworks around it (multiple applications) and since it met my purposes I never reviewed future samples (I assumed they would be similiar and I didn't have the time).

Below is the EmployeesDetailPresenter from their sample:

//===================================================================================
// Microsoft patterns & practices
// Composite Application Guidance for Windows Presentation Foundation and Silverlight
//===================================================================================
// Copyright (c) Microsoft Corporation. All rights reserved.
// THIS CODE AND INFORMATION IS PROVIDED "AS IS" WITHOUT WARRANTY
// OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING BUT NOT
// LIMITED TO THE IMPLIED WARRANTIES OF MERCHANTABILITY AND
// FITNESS FOR A PARTICULAR PURPOSE.
//===================================================================================
// The example companies, organizations, products, domain names,
// e-mail addresses, logos, people, places, and events depicted
// herein are fictitious. No association with any real company,
// organization, product, domain name, email address, logo, person,
// places, or events is intended or should be inferred.
//===================================================================================
using UIComposition.Modules.Employee.PresentationModels;

namespace UIComposition.Modules.Employee
{
    public class EmployeesDetailsPresenter : IEmployeesDetailsPresenter
    {
        public EmployeesDetailsPresenter(IEmployeesDetailsView view)
        {
            this.View = view;
        }

public IEmployeesDetailsView View { get; set; }

        public void SetSelectedEmployee(BusinessEntities.Employee employee)
        {
            EmployeesDetailsPresentationModel model = new EmployeesDetailsPresentationModel();
            model.SelectedEmployee = employee;
            this.View.Model = model;
        }
    }
}

New Post: Patterns

Billkrat — Fri, 22 May 2009 21:47:28 GMT

[mbrownbh] Correct me if I'm wrong in my understanding. But it appears that you have a global presentation model that is shared across views so the views can share state with each other. There is another pattern that would remove this complexity for you called Event Broker (the Prism guidance has a section discussing it and an implementation within the CAL). The idea is that when an event is fired, the broker notifies all interested parties of said event.

Agreed. Excerpt from first message follows:

For example my presenter base will subscribe to the default model's OnPropertyChanged event and call a virtual method so developers can either use the EventAggregator or override this method to be notified on data changes.

I'd like to add that the EventAggregator is a significant part of our infrastructure. Primarily because the EventArgument can contain information only available in the publishing presenter and , unlike parameters, can grow without affecting existing business logic (Microsoft's spin on the "Observer Pattern" - the Event Pattern - is brilliant).

[mbrownbh] Usually, when we talk about Presentation Model (or View Model) there is a 1:1 ratio between the Presentation Model and the View. Josh Smith has an excellent article he wrote for MSDN magazine on MVVM (another name for the Presentation Model pattern). I've never seen an instance where PM and MVP are used together. The primary goal of PM is to make the logic driving your UI fully separated from the UI framework itself.

I'm a Microsoft Crony when it comes to P&P, code and tools. When it comes to Architecture I am a Fowler crony and turn to Microsoft (as I am now) for bleeding edge guidance - I generally don't read other works unless Fowler references them (i.e., Potel paper, "Twisting the Triad", etc). Why? how many of us have heard that in MVP the view doesn't communicate with the model (and this is the distinction between MVC and MVP)? I suspect this stemed from the fact that Fowler split MVP in 2006 and folks saw Passive MVP to be the rule more than the exception where in fact he clearly states that if databinding is present - it isn't Passive MVP. Anywhos...

Martin Fowler says the following about the Presentation Model: http://www.martinfowler.com/eaaDev/PresentationModel.html:

Instead it is easier to consider Presentation Model as an abstract of the view that is not dependent on a specific GUI framework. While several views can utilize the same Presentation Model, each view should require only one Presentation Model. In the case of composition a Presentation Model may contain one or many child Presentation Model instances, but each child control will also have only one Presentation Model.

Thus my infrastructure is based on guidance by Fowler, Microsoft P&P and information provided by Dino Esposito and Andrea Saltarello in "Microsoft.NET Architecting Applications for the Enterprise". As for data I see John Papa as an authoritative source and I have his book on Data-Driven Services with Silverlight 2 (I read his MSDN articles).
There is a consistency among all of them - what is lacking is the complete picture using bleeding edge technologies which forces us to think outside of the box while following existing patterns; my position is that Patterns should be used as tools to meet an objective - if the objective is met then they served their purpose. So the question isn't so much - did I do it right; in the spirit of teamwork if you put 10 programmers in different rooms and assign them the same task it will come out 10 different ways and they will all be right (if they meet the requirement).

Why I rely so heavily on Microsoft P&P is because I don't see what the guru's see; the frameworks ensure my clients are not limited by my architectural knowledge. Sometimes I don't "get it" until it's done (it is very hard to keep up but I'm hanging in there thanks to many patient Microsoft olks like Glenn Block and Chris Taveres).
I think I get it - but now all the rules are changing - we have a fat-client sitting inside of a browser and I'm pushing (and selling) the bleeding edge with no published guidance...

If there is a better way - I'll be introducing it to the team; in the absence of a better way...

New Post: Patterns

mbrownbh — Fri, 22 May 2009 20:17:25 GMT

Correct me if I'm wrong in my understanding. But it appears that you have a global presentation model that is shared across views so the views can share state with each other. There is another pattern that would remove this complexity for you called Event Broker (the Prism guidance has a section discussing it and an implementation within the CAL). The idea is that when an event is fired, the broker notifies all interested parties of said event.

Usually, when we talk about Presentation Model (or View Model) there is a 1:1 ratio between the Presentation Model and the View. Josh Smith has an excellent article he wrote for MSDN magazine on MVVM (another name for the Presentation Model pattern). I've never seen an instance where PM and MVP are used together. The primary goal of PM is to make the logic driving your UI fully separated from the UI framework itself. If that is indeed your goal, I'd suggest looking at Josh's article and moving in that direction (if it's not too late to do so).

On Fri, May 22, 2009 at 3:31 PM, Billkrat <notifications@codeplex.com> wrote:

From: Billkrat

[mbrownbh] There's no reason for the PM to have complex business logic, that's the reason we have a business logic layer. You're saying that you use a presenter AND a presentation model. what's the dependency order? Does the presenter know about the PM and update it appropriately? I guess it's difficult to fully provide advice and guidance on this without a full picture of the system.

[mbrownbh] The link you gave earlier, is that the source code for your system?

It will be the open source repository for the ISO 15926 code; numerous engineering firms around the world have contributed developers to this project. The "IRingFramework: project is based on Prism and the team has already made the decision to refactor the RDSWIPEditor to utilize this framework after the release. The focus has been on the services (AdapterReference and ReferenceData RESTful services). The MappingEditor (within the IRingFramework project) will be the focus for the last week now that the infrastructure is in place.   The UI components have been divided amoung team members and we'll be crunching next week to wrap it up for the News Release at the end of the month.   We try to keep the build intact but since we don't go public until after next week it so it could be in varying states.   The infrastructure and services are intact right now but everything else is conceptual (discussed heavily in developers meetings so we all know what remains to be done when we hit the ground running next week).

The Presentation Model covers cross cutting concerns and is referenced by all of the views in the main InformationModel module. Collectively there will probably be no more than 20 properties concerning both the Adapter and Reference Data entities. It will be a complex search / mapping process on heirachries of data (recursive) where each view's process will be dependent on states set by other views - there is a strong separation so the only thing each view will be able to see is the model (and any events subscribed/published) .    Each Presenter will have the responsibility to respond to events and model changes to perform business logic for it's view requirements. The shared Presentation Model removes a layer of code for maintaining state since the Presentation Model will always reflect the current state of all of the View's interdependent processing (multiple treeViews and property detail list).   A very complex problem that would have been a nightmare to handle without the power of the CompositeWPF, Unity and P&P patterns.

As to the answer to your question in regards to dependency - the following is the wiring up that is done by the PresenterBase, I trust it will answer all of your questions (coupled with the code examples in the first message):

    public PresenterBase(
        IViewBase view,
        IPresentationModel model)
    {
      try
      {
        ModuleFullName = GetType().FullName;

        this.View = (TView)view;

        this.Model = model;
        this.View.Model = model;
        this.View.DataContext = model;

        this.Model.PropertyChanged +=
            new PropertyChangedEventHandler(ModelPropertyChanged);
      }
      catch (Exception ex)
      {
        // Setter Injection doesn't happen until after Construction - lazy instantiation
        // using default Error() class.
        Error.SetError(ex, string.Format("{0}: Could not instantiate PresenterBase {1}{2}",
            ModuleFullName, ex.Message, ex.StackTrace),
            Category.Exception, Priority.High);

      }
    }

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: Patterns

Billkrat — Fri, 22 May 2009 19:30:58 GMT

[mbrownbh] The link you gave earlier, is that the source code for your system?

It will be the open source repository for the ISO 15926 code; numerous engineering firms around the world have contributed developers to this project. The "IRingFramework" project is based on Prism and the team has already made the decision to refactor the RDSWIPEditor to utilize this framework after the release. The focus has been on the services (AdapterReference and ReferenceData RESTful services). The MappingEditor (within the IRingFramework project) will be the focus for the last week now that the infrastructure is in place. The UI components have been divided amoung team members and we'll be crunching next week to wrap it up for the News Release at the end of the month. We try to keep the build intact but since we don't go public until after next week it could be in varying states. The infrastructure and services are intact right now but everything else is conceptual (discussed heavily in developers meetings so we all know what remains to be done when we hit the ground running next week).

[mbrownbh] There's no reason for the PM to have complex business logic, that's the reason we have a business logic layer. You're saying that you use a presenter AND a presentation model. what's the dependency order? Does the presenter know about the PM and update it appropriately? I guess it's difficult to fully provide advice and guidance on this without a full picture of the system.

The Presentation Model covers cross cutting concerns and is referenced by all of the views in the main InformationModel module. Collectively there will probably be no more than 20 properties concerning both the Adapter and Reference Data entities. It will be a complex search / mapping process on heirachries of data (recursive) where each view's process will be dependent on states set by other views - there is a strong separation so the only thing each view's presenter will be able to see is the model, it's view and any events subscribed/published . Each Presenter will have the responsibility to respond to events and model changes to perform business logic for it's view requirements. The shared Presentation Model removes a layer of code for maintaining state since the Presentation Model will always reflect the current state of all of the View's interdependent processing (multiple treeViews and property detail list). A very complex problem that would have been a nightmare to handle without the power of the CompositeWPF, Unity and P&P patterns.

As to the answer to your question in regards to dependency - the following is the wiring up that is done by the PresenterBase, I trust it will answer all of your questions (coupled with the code examples in the first message):

    public PresenterBase(
        IViewBase view,
        IPresentationModel model)
    {
      try
      {
        ModuleFullName = GetType().FullName;

this.View = (TView)view;

        this.Model = model;
        this.View.Model = model;
        this.View.DataContext = model;

        this.Model.PropertyChanged +=
            new PropertyChangedEventHandler(ModelPropertyChanged);
      }
      catch (Exception ex)
      {
        // Setter Injection doesn't happen until after Construction - lazy instantiation
        // using default Error() class.
        Error.SetError(ex, string.Format("{0}: Could not instantiate PresenterBase {1}{2}",
            ModuleFullName, ex.Message, ex.StackTrace),
            Category.Exception, Priority.High);

}
}

New Post: Patterns

mbrownbh — Fri, 22 May 2009 18:49:25 GMT

Okay now it makes a bit more sense to me. Essentially we're advocating the same design, you're just showing the details of the design more explicitly. I can dig it.

There's no reason for the PM to have complex business logic, that's the reason we have a business logic layer. You're saying that you use a presenter AND a presentation model. what's the dependency order? Does the presenter know about the PM and update it appropriately? I guess it's difficult to fully provide advice and guidance on this without a full picture of the system. The link you gave earlier, is that the source code for your system?

On Fri, May 22, 2009 at 12:36 PM, Billkrat <notifications@codeplex.com> wrote:

From: Billkrat

---------------
[mbrownbh] why not this instead              View -> Presentation Model -> BusinessLayer -> DataLayer -> Storage

On the surface (without understanding the context of its usage).   I have a problem to solve with the above - can you shed some light?

=> Who has the responsibility for updating the Presentation Model?   Consider that I use the model across multiple applications/modules so I can't pollute it with business rules

In my case the Presenter updates the Presentation Model (which my view(s) are bound to).

---------------
[mbrownbh] Note that I didn't make any mention in here of WCF or Service Layer. The fact that you're using WCF is an implementation detail that should be abstracted away.

Agreed

---------------
[mbrownbh] Your BusinessLayer would be an interface that can be injected by your container and based on conditions, would give you a local business layer (using a local datalayer and local storage) or a remote business layer that uses WCF to communicate with a remote businesslayer and dal.

Agreed

---------------
[mbrownbh] I think that is what the resistance was. You are essentially removing the benefit of using an IOC container by duplicating the layers on both sides.

Not if you understand the context of it's usage. I have encapsulated reusable components depending on the Business and Data Requirements.   For obvious reasons I don't want to tightly couple by BLL to it's DAL so my Silverlight application has to have both a BLL and DAL - configured as follows (picture says a thousand words):

The following is an excerpt of a single module's configuration for two services residing in a shared project:

    public override void RegisterViewsAndServices()
    {
      Container
          .RegisterType<ILoggerFacade, DebugLogger>()
          .RegisterType<IIMPresentationModel, IMPresentationModel>(
              new ContainerControlledLifetimeManager())

          .RegisterType<IAdapter, AdapterBLL>(
              new ContainerControlledLifetimeManager()) // Singleton
          .RegisterType<IAdapter, AdapterDAL>("AdapterProxyDAL",
              new ContainerControlledLifetimeManager()) // Singleton

          .RegisterType<IReferenceData, ReferenceDataBLL>(
              new ContainerControlledLifetimeManager()) // Singleton
          .RegisterType<IReferenceData, ReferenceDataDAL>("ReferenceDataDAL",
              new ContainerControlledLifetimeManager()) // Singleton

          .RegisterType<IMappingEditorView, MappingEditorView>()

There is a clear separation of concern - other applications and/or modules can use different implementations as P&P suggest

As for IOC in the service ( Service Layer -> BLL -> DAL -> Data Store)

The following is an excerpt of a Service Provider (an implementation of what could be multiple providers) - it benefits from IOC for obvious reasons:

    private IWebHttpClient adapterClient = null;

    /// <summary>
    /// Gets or sets the error.
    /// </summary>
    /// <value>The error.</value>
    [Dependency]
    public IError Error { get; set; }

    [Dependency]
    public ILoggerFacade Logger { get; set; }

    /// <summary>
    /// Initializes a new instance of the <see cref="AdapterProxyProvider"/> class.
    /// </summary>
    /// <param name="container">The container.</param>
    public AdapterProxyProvider(IUnityContainer container)
    {
        this.adapterClient = container.Resolve<IWebHttpClient>("AdapterClient");
    }

I have a single point of configuration for both my application's module and my service (separate applications).   Either can be told to use different BLL / DAL as requirements dictate.   Anything less would have me tightly coupling.

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: Patterns

Billkrat — Fri, 22 May 2009 16:36:45 GMT

---------------
[mbrownbh] why not this instead View -> Presentation Model -> BusinessLayer -> DataLayer -> Storage

On the surface (without understanding the context of its usage). I have a problem to solve with the above - can you shed some light?

=> Who has the responsibility for updating the Presentation Model? Consider that I use the model across multiple applications/modules so I can't pollute it with business rules

In my case the Presenter updates the Presentation Model (which my view(s) are bound to).

---------------
[mbrownbh] Note that I didn't make any mention in here of WCF or Service Layer. The fact that you're using WCF is an implementation detail that should be abstracted away.

Agreed

---------------
[mbrownbh] Your BusinessLayer would be an interface that can be injected by your container and based on conditions, would give you a local business layer (using a local datalayer and local storage) or a remote business layer that uses WCF to communicate with a remote businesslayer and dal.

Agreed

---------------
[mbrownbh] I think that is what the resistance was. You are essentially removing the benefit of using an IOC container by duplicating the layers on both sides.

Not if you understand the context of it's usage. I have encapsulated reusable components depending on the Business and Data Requirements. For obvious reasons I don't want to tightly couple by BLL to it's DAL so my Silverlight application has to have both a BLL and DAL - configured as follows (picture says a thousand words):

The following is an excerpt of a single module's configuration for two services residing in a shared project:

    public override void RegisterViewsAndServices()
    {
      Container
          .RegisterType<ILoggerFacade, DebugLogger>()
          .RegisterType<IIMPresentationModel, IMPresentationModel>(
              new ContainerControlledLifetimeManager())

          .RegisterType<IAdapter, AdapterBLL>(
              new ContainerControlledLifetimeManager()) // Singleton
          .RegisterType<IAdapter, AdapterDAL>("AdapterProxyDAL",
              new ContainerControlledLifetimeManager()) // Singleton

          .RegisterType<IReferenceData, ReferenceDataBLL>(
              new ContainerControlledLifetimeManager()) // Singleton
          .RegisterType<IReferenceData, ReferenceDataDAL>("ReferenceDataDAL",
              new ContainerControlledLifetimeManager()) // Singleton

.RegisterType<IMappingEditorView, MappingEditorView>()

There is a clear separation of concern - other applications and/or modules can use different implementations as P&P suggest

As for IOC in the service ( Service Layer -> BLL -> DAL -> Data Store)

The following is an excerpt of a Service Provider (an implementation of what could be multiple providers) - it benefits from IOC for obvious reasons:

private IWebHttpClient adapterClient = null;

    /// <summary>
    /// Gets or sets the error.
    /// </summary>
    /// <value>The error.</value>
    [Dependency]
    public IError Error { get; set; }

[Dependency]
public ILoggerFacade Logger { get; set; }

    /// <summary>
    /// Initializes a new instance of the <see cref="AdapterProxyProvider"/> class.
    /// </summary>
    /// <param name="container">The container.</param>
    public AdapterProxyProvider(IUnityContainer container)
    {
        this.adapterClient = container.Resolve<IWebHttpClient>("AdapterClient");
    }

I have a single point of configuration for both my application's module and my service (separate applications). Either can be told to use different BLL / DAL as requirements dictate. Anything less would have me tightly coupling.

New Post: Patterns

mbrownbh — Fri, 22 May 2009 15:30:52 GMT

MVP -> BLL -> DAL -> WCF -> Service Layer -> BLL -> DAL -> Data Store architecture.

Why not this instead

View -> Presentation Model -> BusinessLayer -> DataLayer -> Storage

Note that I didn't make any mention in here of WCF or Service Layer. The fact that you're using WCF is an implementation detail that should be abstracted away. Your BusinessLayer would be an interface that can be injected by your container and based on conditions, would give you a local business layer (using a local datalayer and local storage) or a remote business layer that uses WCF to communicate with a remote businesslayer and dal.

I think that is what the resistance was. You are essentially removing the benefit of using an IOC container by duplicating the layers on both sides.

New Post: Patterns

Billkrat — Fri, 22 May 2009 14:25:03 GMT

I'm excited to see how this project evolves. Because of my involvement on the ISO 15926 international development team (engineering companies - I represent Zachry Engineering) I've had to pull out of the open source community (well sorta, kinda - it will be an open source project). The news release hits the airways May 30th so as projects go I trust you know where we (developers) are - crunching...

I thought I'd approach the gurus on an architecture design that has evolved from the things that the various P&P teams have taught me (SCSF, WCSF, CompositeWPF, Unity, etc) and ended up in an infrastructure that combines patterns. MVP, Separated Presentation and M-V-VM. Being on the bleeding edge meant having no guidance (thus my excitement about this project) requiring me to do my best with available knowledge. e.g., I proposed (and we use) the following architecture:

MVP -> BLL -> DAL -> WCF -> Service Layer -> BLL -> DAL -> Data Store architecture.

I always end up debating (various contract teams) the necessity for the Presentation Tier's BLL->DAL as SOA would have us go directly to the Service Layer. Two points that help me win this debate (in the absence of supporting guidance) is a couple of questions. First, what happens when I want to switch to "Isolated storage", after they ask me what this is I let them know that they have a hard drive to code against and could conceptually write a system that caches data. If the service goes offline the module, through DI, could use a IsolatedStorageDAL class (implementing the same interface as the actual service). Second argument is if I have a shared Module (by many applications) I only have to update one assembly if a contract changes on the service. Silverlight changed the rules because it is essentially a fat client but guidance hasn't kept up - perhaps this project??

About the architecture...

I had introduced the team to the CompositeWPF, Unity and Patterns (by Microsoft's definitions) and developed a prototype based on a "Top Down Composition" sample provided in an early drop of the CompositeWPF. Being not to far removed from my ignorance of Dependency Injection, Multi-targeting and separation of concerns, etc, etc, (we didn't have a lot of time - it had to be easy to use). I abstracted much of the complexity into a ModuleLibrary and PrismContrib project (I wanted more projects for a clearer separation of concerns but after much debate I could only get away with these - combining concerns). I think what sold the team was when, during a live WebMeeting, I consumed a service by simply adding an Interface to my constructor, subscribed to the OnDataEvent and handled it - a few minutes work address a business requirement.

As far as project layout, uncomplicated - the primary IRingFramework project has only MVP components and a InformationModelModule.cs. Although they are new to MVP (didn't understand the infrastructure) I was able to quickly show them they need only be focused on the Presenter. I showed off some of the event aggregation and databinding (PresentationModel) as well - powerful stuff. Even in the light of overwhelming time constraints, requirements and lack of experience with the patterns, CompositeWPF and Dependency Injection - the team all agreed to go with it.

My approach...

With the PresentationModel being shared across numerous views (and potentially numerous applications) I found MVP to be very efficient in wiring up the infrastructure (Multi-Targeting) and providing a wealth of opportunities to use different patterns to access and pass data around. For example my presenter base will subscribe to the default model's OnPropertyChanged event and call a virtual method so developers can either use the EventAggregator or override this method to be notified on data changes, they can use either an interface or the Views FindName command to gain references to the Views controls. The shared PresentationModel removes a lot of code overhead having to manage state.

I'd be interested in any thoughts from the Guru's - particularly those that will help streamline debates so we can get coding faster.

With a reference to the CompositeWPF, Unity, ModuleLibrary and PrismContrib projects, the minimal infrastructure code required follows:

Those familiar with SCSF, WCSF and CompositeWPF will be right at home (Hi Glenn :) without even seeing the baseclass code.

-----------[ View ]---------------

System.Windows.Controls;
using PrismContrib.Base;

namespace InformationModel.Views.MEPinnedRegion
{
public partial class PinnedView : UserControl, IPinnedView
{
　　　　public PinnedView()
　　　　{
　　　　 InitializeComponent();
　　　　}
　　　　public IPresentationModel Model { get; set; }
}
}

------[ Presenter ]-------

using OntologyService.Interface.PresentationModels;
using PrismContrib.Base;
using System.ComponentModel;
using System.Windows.Controls;

namespace InformationModel.Views.MEPinnedRegion
{
public class PinnedPresenter: PresenterBase<IPinnedView>
{

　　　　public PinnedPresenter(IPinnedView view, IIMPresentationModel model)
　　　　 :base(view,model)
　　　　{

　　　　}
}
}

----------[ Interface ]------------

using PrismContrib.Base;

namespace InformationModel.Views.MEPinnedRegion
{
public interface IPinnedView : IViewBase
{

}
}

With the interface exposing the following:

using System.Windows.Threading;
namespace PrismContrib.Base
{
　　　　public interface IViewBase
　　　　{
　　　　　　　　IPresentationModel Model { get; set; }
　　　　　　　　object DataContext { get; set; }
　　　　　　　　Dispatcher Dispatcher { get; }
　　　　　　　　object FindName(string name);
　　　　　　　　string Name { get; }
　　　　}
}

The interface provides a hook into the UI that let's me do helper (baseclass) functions as follows which provide alternatives to the code overhead of interfaces:

Button btnSearch { get { return ButtonCtrl("btnSearch"); } }
TextBox txtSearch { get { return TextCtrl("txtSearch"); } }

New Post: Recipe Program

ohanlonp — Thu, 21 May 2009 18:52:34 GMT

That would seem fair. I'm going to download REML and have a scout round it.

New Post: Recipe Program

mbrownbh — Thu, 21 May 2009 17:53:59 GMT

Looking at the list of formats, REML seems to be the most feature complete at first glance. I think leveraging that as our model would allow us to support all the others with a few additions.

On Thu, May 21, 2009 at 7:24 AM, ohanlonp <notifications@codeplex.com> wrote:

From: ohanlonp

I'd be quite happy to mock up a WCF service to return data in different formats, if that would be any help.

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

New Post: Recipe Program

ohanlonp — Thu, 21 May 2009 11:24:42 GMT

I'd be quite happy to mock up a WCF service to return data in different formats, if that would be any help.

New Post: Recipe Program

mbrownbh — Tue, 19 May 2009 20:53:59 GMT

You're right...I've gotta keep focused...hard to do when there's so many shiny objects glimmering around you.

New Post: Recipe Program

wekempf — Tue, 19 May 2009 20:31:09 GMT

Yes, but not really relevant here, I don't think. I'm reluctant to use any real web service, because it complicates what's necessary to run the application in many scenarios. I think it's a much better idea to mock the web services.

On Tue, May 19, 2009 at 3:52 PM, mbrownbh <notifications@codeplex.com> wrote:

From: mbrownbh

Hmmm...that'd be interesting as an Azure app.

On Tue, May 19, 2009 at 11:40 AM, wekempf <notifications@codeplex.com> wrote:

From: wekempf

I'm not aware of any existing online services. I imagined we'd mock a service (i.e. it wouldn't ever really hit the wire, and would instead just return canned data) to simulate asynchronous processing.

On Tue, May 19, 2009 at 11:18 AM, MichaelLPerry1971 <notifications@codeplex.com> wrote:

From: MichaelLPerry1971

This being a client-side MVVM reference, the social features seem out-of-scope. But we do want to demonstrate asynchronous processing, so communication with an external service would be an excellent example.

Are there any recipe-oriented services that already have an API? The MealMaster link seems promising. Is there already an instance running that we can use?

I'm thinking that the MVVM reference application can be a smart-client for an online service. If we don't have to write the online service ourselves, then the RIs can focus on implementing the pattern.

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

Read the full discussion online.

To add a post to this discussion, reply to this email (mvvmref@discussions.codeplex.com)

To start a new discussion for this project, email mvvmref@discussions.codeplex.com

You are receiving this email because you subscribed to this discussion on CodePlex. You can unsubscribe or change your settings on codePlex.com.

Please note: Images and attachments will be removed from emails. Any posts to this discussion will also be available online at codeplex.com

--
Quidquid latine dictum sit, altum sonatur.
- Whatever is said in Latin sounds profound.

War is peace. Freedom is slavery. Bugs are features.