• Lesson 1 – Prism NW -Starting our first Prism/MVVM app with dynamic regions

    First I would like to thank all of those before me for all their hard work and examples.
    In particular:
    Sacha Barber as I’ve found his Cinch sample to be most helpful for WPF. If you look at NSVMVVM you’ll see it’s mainly made up of Cinch with a few minor mods.

    Josh Smith – I don’t know Josh personally but he has contributed quite a bit to WPF & MVVM. Also, these lessons will utilize some of his work such as the RelayCommand.

    Also, I would like to thank Telerik and all the support they provide me with their controls allowing me to design rich, LOB apps. I will be using their controls in these applications

    If you aren’t familiar with Prism, I suggest you download the latest version. The latest at the time of this writing was Oct 2009. http://www.codeplex.com/CompositeWPF

    For a list of the DLL’s you’ll need to work with Prism, please check out the following documentation
    http://msdn.microsoft.com/en-us/library/dd458867.aspx

    From that link you can read all the other Prism documentation.






    The first lesson will go into layout of the solution and get us prepped for future lessons. There will be no code for this lesson.

    Let’s dive in. In our NSTPrismSample, we have a WPF application called NSTPrismSample.

    We have modules for Customer, Employee and Order. I chose these three modules as within a lot of applications we’ll do our best to design modules to contain similar functionality. However, there will inevitably come a time where you need to use functionality from one Module in another. As with the case for this sample, we have an order module but need order functionality for both Customer & Employee. An argument for the real world that all three of these could make up a module but for I chose this layout for demonstration purposes.

    We then have the Infrastructure project. To those not familiar with Prism, anything you have that may need to be shared in all the modules, best practices are you place them in an Infrastructure assembly.

    Finally, you’ll notice an NSVMVVM assembly. Essentially this is Sacha Barber’s cinch with a few minor additions to date. For more info about Cinch, Sacha has some wonderful tutorials located at:

    http://www.codeproject.com/KB/WPF/Cinch.aspx

    In the modules you’ll see through these lessons, I choose to create the following folders.

    View – Self explanatory and contains the views that will put our data to the glass so to speak. There are some different rules of thought here. Some claim there should be no code behind. Some say it’s ok. My thoughts are it’s ok to put View specific code in the code behind and no business logic. That should go into your ViewModel so it’s easier to test.


    ViewModel – For me, this is where I put all the functionality needed by the view to interface with our module Models & Services.

    Service – Contains code that will allow us to interface with our data provider. This could be to our database, WCF service etc.

    Models – This is where I place all objects needed to represent the data being returned from our service to our application. These objects are formatted as necessary to utilize the benefits of WPF such as data binding. I really like what Sacha has done with Cinch and his DataWrappers which gives up INotifiedChange, Validation with IDataErrorInfo etc.

    Events – For any events I need to define that pertain to the module. If they are global commands for use with the Eventaggregator, they go into the Infrastructure assembly.

    Controllers – I use controllers if I have a need to apply logic if a view or service is needed in multiple scenarios. This can get confusing if you are just starting to read as a controller in the MVC functions in a similiar fashion to the View Model in MVVM.

    For now, I mostly do this when I have a view in a module that needs to be loaded differently based on some input. Like what you’d get when you’re sharing a module view with other modules.

    That gets us through the basics. If there are any questions on the base project or anything I left out, please let me know.

    In lesson one, the sole goal was to get our feet wet with some concepts. I'm trying to break everything out without overloading everyone in any one lesson.

    At least with the first couple of lessons. Please see Lesson 2 to get a look at the code for the concepts described in this article.
    Comments 4 Comments
    1. rgramann's Avatar
      rgramann -
      I think Controllers should also be considered if you need to persist application state across Views. ViewModels should not be registered as a Singleton, therefore any data associated with it will be lost when loading/unloading. You can use a Controller to capture and retain this data.
    1. frosty's Avatar
      frosty -
      Agreed. Have you looked into the new Caching object in .Net 4.0 for retaining data? I plan to look into it and the Observern Pattern included in .Net 4.0 to see if it's a viable alternative to the Event Aggregator in Prism.
    1. rgramann's Avatar
      rgramann -
      Hmm...Caching Object? No, just having a look around with 2010, nothing serious. Sound promising though. What's wrong with the EventAggregator?
    1. frosty's Avatar
      frosty -
      Yes, looks like they've created a caching object to be used in Windows, WPF & Asp.Net.

      Here's a link to Advanced Development features in 4.0.

      http://msdn.microsoft.com/en-us/libr...v=VS.100).aspx

      Personally, I don't have issues with the EventAggregator so far but I've heard complaints of it being too "heavy". Plus for me, I like Prism but if I tend to lean towards utilizing objects that exist in the .Net framework versus add-on frameworks.

      Right or wrong, I tend to believe if they put it in .Net, then it's apt to be around longer. Plus if I can get by without using add on assemblies, it's less maintainence for me in most cases.

      So now if anybody is trying to use MVVM and they only use Prism for EventAggregator, it looks like they can utilize the Observer<> object. I haven't verified that but judging by the following comments, it looks to be the case.

      "The observer design pattern is suitable for distributed push-based notifications, because it supports a clean separation between two different components or application layers, such as a data source (business logic) layer and a user interface (display) layer. The pattern can be implemented whenever a provider uses callbacks to supply its clients with current information. "


      Actually, I've contemplated looking at MEF as a replacement for Prism since it's built in. My holdbacks up until now is spending the time to make sure there aren't any limitations. I like regions in Prism. Also, I have to wonder with what little I've seen of MEF if it goes too far in cutting out code. I'm afraid performance and also debugging may become issues with an enterprise application.
  • Tag Cloud