Patterns

May 22, 2009 at 3:25 PM
Edited May 22, 2009 at 3:36 PM

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"); } }

 

 

May 22, 2009 at 4:30 PM

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.

May 22, 2009 at 5:36 PM
Edited May 22, 2009 at 7:15 PM

---------------
[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 my 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.

 

May 22, 2009 at 7:49 PM
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


May 22, 2009 at 8:30 PM
Edited May 22, 2009 at 8:59 PM

[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.  The MappingEditor 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 Microsoft P&P.  

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);

      }
    }

May 22, 2009 at 9:17 PM
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


May 22, 2009 at 10:47 PM
Edited May 22, 2009 at 10:56 PM

[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 folks 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...

May 27, 2009 at 12:27 AM

[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;
        }
    }
}