Goals

Coordinator
Apr 13, 2009 at 8:04 PM
OK, here's the beginning of the dicussion of goals for the project. This is all stream of concious and very open to debate and elaboration.

We're looking to build something along the lines of Pet Shop, but specific to Model-View-ViewModel in WPF/Silverlight.  At this point, we have no idea what the reference application will be, but should be discussing what any such application should include for wide applicability as a reference application for any M-V-VM framework.  Some ideas I've had so far:

* Compatible with WPF and SL.
* As "real" as we can get.
* Illustrate "common" scenarios.
    * Need to flesh out "common" scenarios.
        * Navigation
        * Communication between "views"
        * Commanding
        * Event handling
        * MessageBox
        * Focus control
        * Selection (particular multiple) tracking
* Needs to be complex enough without being too complex.
* Things we should provide from a CodePlex project:
    * Complete business/domain model assembly.
    * Unit tests for the business/domain model.
    * Reference implementation of the UI done using "traditional code behind spaghetti without VM".
        * Provides UI assets like images and styles that other implementations can use.
        * Provides a complete implementation to compare to that doesn't deal with M-V-VM, illustrating why M-V-VM is beneficial.
        * No tests provided for this reference, as it's "impossible" to test "code behind spaghetti".
        * No VM implementation because the V implementation doesn't use one, and because a VM framework may want to illustrate VM base classes or other features.
        * Probably in WPF and not SL for simplicity, though SL frameworks should be able to "port" the application.
Apr 13, 2009 at 9:22 PM
Great goals. My personal goals are:

  • Demo the blendability of a MVVM application
    • How to create Design time code to support the designers
      • Design time code can be either in line in the VM class, or using a dependency injection pattern, in a "design time implementation" of an IVIewModel interface.
    • What happens in a non MVVM application
      • Blend doesn't like that and it is hard to design there, but still possible. Maybe give tips and tricks, but underline the advantages of the VM way.
  • Testability of the VM
    • Synchronous (easy)
    • Asynchronous (not a VM topic per se, but really useful especially for Silverlight)
  • How to share code between WPF and SL applications
    • Goal: Simplify the development on multiple platform, share as much code as possible (which is made much easier if the application is layered properly, hence the MVVM approach)
That's all for now, more to follow later ;)

Laurent
Apr 13, 2009 at 9:48 PM
The application should be fully documented and designed.
Design decisions should be documented and explained.
The design should include items such as use cases, storyboards, deployment diagrams and the like.
Apr 14, 2009 at 12:14 AM
I think the Prism RI (the stock trading app) is as good as any. It gives us a good foundation and opens up options for very rich Business Logic and Dataviz scenarios.
Apr 14, 2009 at 8:16 AM
This is great stuff if you will be able to produce an understandable and clean reference implementation with techniques you disciples used in your day to day WPF development.

One thing that seems missing from the above lists is exception handling and presenting this to the user. Looking forward to see the final project.
Apr 14, 2009 at 8:39 AM
I agree, Exception handling and validation should be in as well...

The most important thing is that we keep this as simple as possible implementation wise.... I know it is hard but if we fail on that one it's better if we don't do anything at all.....
Coordinator
Apr 14, 2009 at 9:28 AM
Laurent,

The "Blendability" goals sound great... but I'm not sure how we'd accomplish that here.  Sounds like a great goal for an M-V-VM framework to do when re-implementing this reference application, though.  If you've got any thoughts on how we could achieve this goal when keeping in mind that implementers are free to do what ever they want when creating specific reference implementations, then let us know.

Testability is similar.  One of the goals I stated was that we'd not provide ANY ViewModel code.  That's what specific re-implementation are responsible for doing.  That said, the bit about async sound intriguing and might be something we can sort of "force" on the implementers.  Could you elaborate on this?

The stuff on sharing code is firmly in the realm of the M-V-VM frameworks themselves.  I don't believe that should be a goal in the reference implementation.  If an M-V-VM library is strictly usable only in WPF or Silverlight, we don't want to exclude them from implementing the reference application.

We have to remember, this isn't an M-V-VM framework.  This is simply a reference application that is intended to be implemented by existing and future M-V-VM frameworks to showcase how those frameworks can be used to solve typical difficult scenarios that occur in common application development.
Coordinator
Apr 14, 2009 at 9:30 AM
Peter,

Great points about documentation.  This is going to be especially important for this, because we expect developers to implement something very specific, in order to be able to compare and contrast solutions using various M-V-VM frameworks.
Coordinator
Apr 14, 2009 at 9:32 AM
Mike,

I don't want to focus on what application to build just yet.  It may be that the Prism RI is perfect... though honestly, I have my doubts.  The Prism RI focused heavily on component application development, and I don't believe we should be doing that here.  In any event, we'll discuss for a little longer what the goals and requirements are, and then move on to figuring out what the reference application should be, and if the goals/requirements fit the Prism RI, then great.
Coordinator
Apr 14, 2009 at 9:37 AM
huseyin and Marlon,

Exception handling is important, but I'm not sure if it matters much to M-V-VM, unless your talking about using exceptions for validation?  Could someone expand on this one?  Validation is most certainly a requirement that should be on the list.  I'll expand that a little and state that we should do both forms of validation: immediate validation and asynchronous validation on save.
Apr 14, 2009 at 11:00 AM
Edited Apr 14, 2009 at 11:21 AM
When I said the Prism RI was a perfect app, I was referring to the domain itself (stock trading) and not necessarily the componentization of the application. Prism's forte is indeed componentization and I'm sure their RI would highlight it. Another MVVM framework might not go that far. But I think people understand the basics of stock trading so the details of the app won't get in the way TOO much. On the other hand, we also want to show how MVVM can be used to address complex business logic, and it doesn't get more complex than stock trading.

But I agree with you, maybe we should keep this talk focused on goals.

I also think that even beyond the Domain Model, we should provide database schemas and even a basic DAL. This way the frameworks don't need to implement this code themselves if they don't want to. (If a specific framework has certain design constraints and/or shines better with a given data access model, they are free to show off this capability).

I think that some of the goals mentioned by others even if they don't become full goals of the base RI should be suggestions for desirable qualities in a framework and guidelines on what frameworks providers should attempt to highlight in their implementation.
Apr 14, 2009 at 11:42 AM
Hey Bill,

Yes my comments must be understood as being part of the MVVM re-implementation of the reference application. A non MVVM implementation will make all these goals extremely difficult to reach in my opinion. This is what I wanted to underline.

Unit testing asynchronous operations has nothing to do with MVVM per se, but is a problem that every unit tester will encounter sooner or later (especially with distributed applications, and especially in Silverlight where async is the rule). There are solutions, and I thought it would be a good place to case study various solutions to that problem.

Cheers,
Laurent
Apr 14, 2009 at 12:10 PM
Great Idea!

I think Family.Show from Vertigo might be also a good candidate for MVVM: http://www.codeplex.com/familyshow

Validation and "Blendability" are for me to topics that should be addressed! 

Regards
Laurent
Coordinator
Apr 14, 2009 at 12:24 PM
Mike,

I considered the Domain Model to include everything necessary at that level.  Whether that includes database schemas or a DAL will depend entirely upon what the application is.  A Twitter client isn't going to need a schema, for instance.  But yes, the implementation should include EVERYTHING required at the domain/business level, so that implementers need focus only on the View and ViewModel.

And yes, stating suggestions on desirable qualities of a framework is a good idea... though we have to be careful there.  Targeting both WPF and SL is a fine goal, but probably not one that's general enough to be a stated goal of all frameworks that should take advantage of the RI here.
Coordinator
Apr 14, 2009 at 12:33 PM
Laurent (Bugnion, since we have to Laurents posting here),

Discussing goals/requirements for re-implementations is probably valid, though it risks taking the discussion in the wrong direction if we can't tie it directly back to goals and requirements of the abstract (non-MVVM) RI.  We need to be able to state functional goals that are likely to lead to or highlight framework designs meeting the implementation goals.  So including asynchronous operations, for instance, is a great requirement.  What a concrete RI does to solve the issues caused by this is up to that specific RI.

The WPF/SL goal I think I already addressed when I stated that it should be possible to implement the RI in SL (though I don't expect our non-MVVM implementation to do so... though that's certainly open to debate).  The Blendability goal is tougher.  It sounds great, but I don't know how we'd introduce this here.  We should use Blend to implement the non-MVVM RI, but beyond that, I see know way to "encourage" this, other than documented as a "suggestion for desirable qualities" as Mike points out.  Do you have any thoughts on how to go further with this one?
Apr 14, 2009 at 12:43 PM
Sounds great. Here's a couple of my thoughts:

On Blendability / design time experience: provide guidance and examples on when to use Commanding and when to use Behaviors.
On portability (sharing code): Perhaps not applicable to a large crowd, but I've been experimenting with MVVM implementation for Windows Forms apps so maybe a couple of hints for WinForms developers to help easier portability to WPF/SL could be helpful.
Coordinator
Apr 14, 2009 at 12:48 PM
andrejt,

Nice suggestions.  As Pete mentioned, documentation is going to turn out to be one of the biggest contribution made by this project.  There's no way we're going to address WinForms in code, but including a specific guidance document for this might be doable.
Apr 14, 2009 at 1:15 PM
If we're going to involve Blendability and documenting design work, I think the project needs a dedicated Visual Designer.  Otherwise it's just make believe.
Coordinator
Apr 14, 2009 at 1:21 PM
Josh,

I agree totally.  Even if we didn't involve Blendability and documenting design work, I think it's a good idea to have a real designer help with the base RI.  So, at some point, we're going to need to recruit someone.
Apr 14, 2009 at 1:24 PM
If with Blendability you mean creating behaviors so that attaching commands to elements can be done visually i totally agree, otherwise i don't understand how the Blend thing fits into the project.

-Corrado
Coordinator
Apr 14, 2009 at 1:32 PM
Corrado,

I mostly have the same concern.  We won't include any behaviors here as this isn't an M-V-VM framework, nor will our UI use M-V-VM at all (sounds contradictory to the stated goals of the project... but the point is for others to re-implement the application using an M-V-VM framework of their choice).  So I don't see anyway to make blendability a goal, other than in documenting it as best practice for M-V-VM frameworks.  Like I said, we should make use of a designer using Blend in the base RI, but that doesn't do a thing towards the "Blendability" of the final RIs.
Apr 14, 2009 at 1:39 PM
I'm looking forward to contributing to this project in any way I can. Prism was one opinion. I think there is room for a different one.

Toward the goals of communication between views and navigation, I think that Update Controls has a good story to tell. If you don't mind taking a dependency on another Codeplex project, I'd like to flesh that out.
Apr 14, 2009 at 1:42 PM
@Corrado: This is not what I meant by Blendability. What I meant is that if you want to enable your designers to work in Blend, MVVM makes it a lot easier. I don't mean to impose blendability on the reference implementation, rather that we should document how much better blendability is when MVVM is used. Maybe I still didn't totally understand the purpose of the reference implementation though.

@Josh: Yes we should try to get a designer. Two names come to my mind immediately: Robby Ingebretsen and/or Nathan Dunlap. Let me talk to both and see if I can get them on board.

That said, in my experience, Blend is used by integrators much more than by designers. But having a designer on the project would totally reinforce the project's credibility.


Apr 14, 2009 at 1:54 PM
Just want to precise something: When I talked about blendability of the MVVM reference implementation, I meant that it would be good to show how to create design time data in the view models. There are multiple ways to do that.

Also, often Blend displays an exception, for example when the VM attempts to connect to a DB or to a web service, and we can show how to prevent this in the VM.
Apr 14, 2009 at 1:55 PM
I think that's a great idea, LaurentB.
Coordinator
Apr 14, 2009 at 2:03 PM
@MichaelLPerry1971: There's still some confusion about what the goals here are.  I need to add a FAQ explaining it better than has been done thus far.  This project isn't going to give ANY solutions to M-V-VM.  What it is going to do is provide a sample application that does "typical" things that cause problems when following an M-V-VM architecture.  Then, given this reference application and supporting documentation, other implementations can be made using specific M-V-VM libraries.  Those other implementations won't be part of this project (though we'll provide links to them).  Instead, they'll be reference implementations provided (probably) by the specific M-V-VM library's author(s).  This makes it easier on the library developers, since they don't have to dream up their own RI sample.  It benefits the users, since they can compare various RIs using "competing" libraries, and they can learn "best practices" of how to use a given library.  Again, if you're at all familiar, this is "Pet Shop" for WPF/SL/MVVM.  So Update Controls won't be used here, but if you want to build an RI based on what this project provides using Update Controls, that sounds great to me.

@lbugnion: I think you understand what the purpose here is.  At least this latest post makes a whole lot of sense to me.  I just didn't quite understand where you were going with your initial post.

You're correct about the difference between a designer and an integrator.  I'm lucky here... our designer is also a competent developer and does some of all three role's responsibilities (even though his core is as a designer), and does his design work mostly in Blend (with other tools for images).  I'm not too hung up on what tools get used here, but I think we need competent designer(s) and the XAML should be mostly produced in Blend.  Like you say, this will reinforce the project's credibility.
Coordinator
Apr 14, 2009 at 2:57 PM
@lbugnion: The design time data idea is great, though I'm not sure where to go with it.  I just don't have expertise there, but providing design time data "assets" in some form sounds great to me.
Apr 14, 2009 at 3:33 PM
Edited Apr 14, 2009 at 3:39 PM

I think we have a lot of good points already enlisted, from my perspective I think we need to ensure:

  • The ref app should be LOB related, I think that gives us the best buck for the money. It is also a topic that a lot of developers can easily related to, especially the ones who will end up taking the decision on using M-V-VM. So I don’t think Vertigo’s Family.Show is a good model app!
  • Also the core scenarios that we address need to be both “meaty” and varied.. The ref app for Prism, is essentially like one screen that isn’t really reflective of M-V-VM, rather it highlights the strengths of Prism with relative simplicity. We need a solid domain model, and some significant scenarios that we address head-on.. the Pet shop had that, and tackled a couple of scenarios!
  • I am good with highlighting async operations and it’s consumption from both off and on the UI as it is quite an important pattern
  • Blendability is a tough call, I’d like to have that/it but would prefer a solid demonstrations of principles rather..  So some kind of support documentation/tips are a reasonable compromise.. 
  • I think we should perhaps have some kind of side-by-side notations from all implementations, on how they approach and resolve each granular problem/situation with special emphasis on M-V-VM..

Rishi

Apr 14, 2009 at 3:51 PM
Edited Apr 14, 2009 at 4:01 PM
I think we also need guidance/ref impl on Asset management, something along the lines of the AssetExtension I created sometime back. Also it would be good to have some conventions for Code and Xaml. Paul Stovell's article on Xaml naming conventions would be applicable here.
Coordinator
Apr 14, 2009 at 3:53 PM
@Orktane: With regards to LOB, I lean heavily in that direction myself, but I'm not sure we should necessarily limit our horizons in that regard just yet.  It's possible someone could come up with an interesting application idea that fullfills all our other requirements that we find to be compelling.  I'd agree, though, that I don't think Family.Show quite fits, though I can't give a concrete reason beyond it not being applicable enough to LOB developers. I'd say, if it's an application like something most of us have or will develop and it covers the goals, the type of application is not all that important.  Pet Shop was a good choice not because it was LOB, but because it was a common application type that nearly everyone could relate to.

The "meaty" comment I agree with totally, and was what I meant when I described it as "real".

The side-by-side notations idea is solid... but we won't have (nor should have) any control over what any of the concrete implementations do.  One would hope, that like with Pet Shop, the developers see the benefit in documenting this sort of thing, and just do it.
Coordinator
Apr 14, 2009 at 3:55 PM
Oh... another goal we should include: common dialogs.  File open/save are the most obvious candidates, but some usage of common dialogs should be included, as this is a definite "pain point" that people struggle with.
Apr 14, 2009 at 3:57 PM
Common dialogs are a definite must.  I have seen innumerable questions on how to show dialogs, messageboxes, etc. when using MVVM. 
Coordinator
Apr 14, 2009 at 4:05 PM
@pavanpodila: Hmm... the scope here is creeping a bit.  Pet Shop didn't provide this sort of guidance, and I didn't envision going this far.  Maybe it is a good idea, though?  What do others think?  Should this have a narrow focus on being a reference implementation sample, or do we get heavily into guidance?  Is there danger in restricting library authors if we get too heavily into guidance?
Apr 14, 2009 at 4:25 PM
Bill,
        If this is going to be out of scope, we can probably consider this for the next revision. I definitely don't want us to digress from our main goals.
Apr 14, 2009 at 4:45 PM

I just search MSDN for sample applications, here are a couple of them that seemed significant..

.NET StockTrader Sample App – this is for WCF with some configuration tools

IBuySpy – I think it demonstrates ASP.NET and SQL

Help Desk Sample Application – I think this too highlights SQL, not sure though

Human Resources Skills WinApp – I think this was for ADO.NET

Northwind Remote Salesforce RDA Sample Application – this is RDA on Win Mobile

These are just for some perspective, not for recycling the scenarios.. Also I think we ought to have the same app/scenario for both SL and WPF, this would be helpful in conveying how M-V-VM can help with multiple “views” with minimal changes.. which is a solid selling point!

BTW, what the timeframe for implementation?

Coordinator
Apr 14, 2009 at 4:52 PM
@pavanpodila: I don't know if it's out of scope.  It's beyond the scope of Pet Shop, which was all I had originally envisioned.  However, I'm open to discussion about what the scope should be for us.

@Orktane:  We don't have a timeframe yet.  A little hard to have one when you don't know what the requirements/goals/scope are yet ;).  I figured we'd discuss the goals/requirements for another day or two.  After that, we'll move on to figuring out what the sample application will be, which probably will take a day or two.  Then we can move on to determining work items and assigning work to volunteers.  It would be nice if we could start working on work items within a couple of weeks.  I have no idea about time frames for any sort of release.
Apr 14, 2009 at 5:14 PM
Wow...stepped away to take the baby to her checkup (doing just fine BTW) and come back to this avalanche. I just wanted to make a point on "Blendability" as a point of consideration when looking at MVVM frameworks (not sure if this has been addressed yet) to me MVVM is all about simplifying the Dev-Designer Workflow. In my series on refactoring WPF, on which I've made significant progress for the next post, I will be talking heavily about the D-D workflow specifically about how MVVM allows me to create a very rough prototype that shows the primary elements / interaction for the UI and toss it over the fence to a designer to prettify it. I definitely think that should be one of the points of consideration in the list.

I agree with others that this effort should be documentation heavy, maybe to the extent of even providing a "lap around WPF" section. That being said, I think we need to come to an agreement on the licensing for the documentation we write. Do we go Creative Commons, Public Domain, or something more restrictive?
Coordinator
Apr 14, 2009 at 5:21 PM
Along the lines of the list Orktane posted, here's a great list of M-V-VM related blog posts that I found on StackOverflow.  http://tanguay.info/web/index.php?pg=notesItems&id=28
Coordinator
Apr 14, 2009 at 5:24 PM
@mbrownbh: Licensing is something else to discuss (probably should start another thread for it though).  For the code I had to create an "empty" repository and choose a license in order to publish this project.  I chose MS-PL for simplicity, but I'm fine with discussing that as well.
Apr 14, 2009 at 5:28 PM
OK, I understand the "reference application" concept a bit better now, and now I am even more excited to participate than before.

I will definitely be creating a library implementation after the reference application has been defined. Probably in parallel with its definition. Does this create a conflict of interest on my part? To what degree can I still contribute to the reference application?

As to the scope of this project, perhaps we need to attack it from the viewpoint of "Why MVVM?" If we can answer that question -- why would someone choose MVVM in WPF and SL over some other pattern/platform -- then we'll have the basis for generating requirements.

My thoughts on why MVVM:
  • Composability
  • Developer-designer-integrator workflow (a.k.a. "blendability")
  • Separation of concerns
  • Persistence ignorance (local vs. remote)
Apr 14, 2009 at 5:29 PM
I'd add Testing

-Corrado
Coordinator
Apr 14, 2009 at 5:37 PM
@MichaelLPerry1971: No, there's no conflict of interest there.  Most of the current (known by us) M-V-VM libraries have representatives participating here (for a list of those project, see the home page of this project, which I updated earlier today, and just so you know, I'm the author of one of them).  If anything, I think participation by existing and planned M-V-VM library authors is essential to getting this right. :)

As for your comments about why MVVM... you're right, enumerating them could be helpful.  Since most of us are MVVM "evangelists", it didn't occur to me that we should clarify this.  As Corrado pointed out, though, your list missed THE most important reason for using MVVM: testing.
Apr 14, 2009 at 5:48 PM
@Mike We mentioned Blendability (in the sense of improving the designer-developer workflow) in the thread already, thanks to confirm it is also important to you

@MichaelLPerry1971: We started this because the WPF disciples are wanting to create a simple MVVM framework, so we will probably all be involved into the reference application and into the framework implementing it. I don't see an issue either, since we are all experienced developers and able to separate the concerns. I will just wear two different hats I guess ;)

@Bill: The most important reason to me is blendability. Testability is the second most important. :) I guess it all depends on the role in the project ;)
Coordinator
Apr 14, 2009 at 5:55 PM
@lbugnion: Yeah, I'm sure everyone would rank the reasons differently, especially based on one's role in development.  However, from a business stand point, I think testability out ranks blendability.  I'll also point out that both of these reasons are enabled by the separation of concerns, so from a technical point of view, I guess that one really outranks the rest. ;)
Apr 14, 2009 at 6:11 PM

I think MichaelLPerry1971 made a great point about “Why MVVM”? That introspectively should be the guiding principle for the scope of this project..

Coordinator
Apr 14, 2009 at 6:14 PM
@Orktane: I'm not certain how the "why" helps us define the scope.  The why doesn't tell us whether or not we should include MVVM guidance documents, for instance.
Apr 14, 2009 at 6:19 PM
The question "why MVVM" could help us define the scope of the reference app itself, not necessarily of the guidance that surrounds it. I think we should come up with an app that people would choose to develop with MVVM and WPF or SL. If the app is better served by a different patter or platform (heaven forbid!) then it is not a good candidate.
Apr 14, 2009 at 6:25 PM

I meant primarily in terms of the feature-set, so a scenario that shows say “separation of concerns”, we can reflect on that and say this shows “Why M-V-VM” is a good prescription. Basically, the features in the model app, should showcase the answers to “Why M-V-VM”.. if you get my drift..

Coordinator
Apr 14, 2009 at 6:40 PM
@MichaelLPerry1971 and @Orktane: If it's a GUI application, it's best implemented using MVVM, IMHO.  Now platform... that's a harder.  Unless we go with something very media oriented, I'm not sure you can definitively make a case that WPF/SL are the "best" choices (though as a Disciple, I've got a strong opinion that it is!).  So I'm not entirely sure "why" is going to help us choose an application to implement.  It may help us in thinking about more technical requirements, like using common dialogs (hard to test if in the VM), but I just don't see "why" helping all that much with the final application choice.
Apr 14, 2009 at 7:06 PM
The "How MVVM" will definitely point out "Why MVVM" and all participants in this discussion know their "whys", although perhaps in different preference order. For me,  portability (WPF/SL/WinForms) and blendability are close to the top. With separation of concerns, as mentioned, being "the one" that enables a number of more specific reasons.
Also, perhaps the future discussions should focus on those not-so-trivial aspects of MVVM, like the already mentioned dialogs and V/VM separation in whole (what can be contained In-the-View only and where the VM comes in; for example: is a delete confirmation dialog a View-only thing or is there VM involved).
Anyway, the How should make it clear as to Why.
Coordinator
Apr 14, 2009 at 7:21 PM
@andrejt: The "how" is in the realm of the implementations, not this project. For example, in many M-V-VM libraries, the dialog example is handled with code in the View (possibly executed because of an event raised by the VM).  In Onyx, this isn't the case.  The VM displays the dialog through the use of a dialog service. This is going to be a very opinionated part of every library, and hows no place in what we produce here. Now paying attention to things where the "how" is a common "pain point" for developers makes a lot of sense, and that's where many of the current goals/requirements came from.
Apr 14, 2009 at 8:36 PM
@all ;-> It's coming across loud and clear that the documentation side is going to be very, very important. It seems to me that the reference app will give guidance to where the "hook points" will be, and what they are to accomplish - the how will then be up to the individual implementers. To a certain extent, this is going to be the WPF Zen Garden app that I posted about a few months ago (in the Disciples forum). Woo hoo.
Apr 14, 2009 at 8:41 PM
I'm sure I will never find the one true pattern, but your point is well taken. We are going to define a GUI application. We are going to use MVVM. We are going to build multiple references to explore different opinions on implementation.

So the application should demonstrate all of the features that make MVVM superior. Should we start listing those features?
Apr 14, 2009 at 9:18 PM

I still think the “why” helps us in selecting the feature-set of the ref-app, and like MichaelLPerry1971 again said we should concertante/highlight the features that make M-V-VM distinctive/ superior /special. So if we get a list of those features, then we can check whether or not a particular ref-app scenario best highlights what we think are the distinctive/ superior /special qualities of M-V-VM. It kind of becomes our evaluation cheat-sheet to move forward.

Coordinator
Apr 15, 2009 at 12:20 PM
Hmmm... I'm still not sure "why" helps, but let's explore it.  So far, the various "why" reasons given, to me, kind of sum it all up, and none of them seem to lead to any goals/requirements that haven't already been enumerated.  Can you guys flesh anything more out?
Apr 15, 2009 at 1:17 PM
Not sure is this is completely relevant but I would like to see support for loose xaml.
Apr 15, 2009 at 1:19 PM
Here's an example of how "why" helps us spec a reference app. Take the "why" of composability. Use it as a standard against which to measure two candidate reference apps: point-of-sale and CRM.

The point-of-sale system has a register view, with which the user rings up items. This view is composed of the check, the catalog of items, and methods of payment. On a scale of 1-10, how well does this app demonstrate the feature of composability? I'd rate it about a 6 because the composite view is all in one place, and there is limited need for interaction between the components.

The CRM system has multiple views: leads, customers, offerings, sales people. Multiple instances of these views can be open simultaneously. Changes in one view affect the others. How does this app measure up against the composability standard? I'd rate it a 9 or 10.

List the benefits of MVVM, weight them, and hold up several candidates against that standard. Then we'll have a mechanism by which to select an appropriate reference app.
Coordinator
Apr 15, 2009 at 1:21 PM
@smesser: Can you flesh that out?  Loose XAML is an implementation detail, and we can't really force any implementation on the final RIs.  However, we may be able to figure out a way to include functionality that addresses pain points caused by loose XAML.
Apr 15, 2009 at 6:08 PM
Edited Apr 15, 2009 at 6:09 PM
Let me take a stab at converting the benefits of MVVM into requirements for a reference app.
  • Testability - The app specification should include some complex business and interaction rules, not just CRUD. Good fodder for showing off tests.
  • Composability - The app specification should call for multiple related views. A requirement for a plug-in infrastructure would be a big plus.
  • Blendability - The app should be one that is differentiated by a well-designed UI. Usability by both novice and expert users should be considered a strength. A non-traditional experience would be a plus. RIs should have to borrow XAML resources from the spec.
  • Separation of concerns - An RI requirement, not an app specification requirement.
  • Persistence ignorance - The app specification should call for a client/server or distributed system. Perhaps smart-client caching should be required.
In addition to choosing an app specification that demonstrates the strengths of MVVM, it also appears to be important to choose one that demonstrates the challenges of the platform. Some examples culled from the comments above:
  • Common dialogs
  • Asynchronous processing
  • Shared resources between WPF and SL (and server?)
  • Validation
  • Data access (support for your choice of ORM?)
Please add and subtract.
Coordinator
Apr 15, 2009 at 7:00 PM
Testability - Yes, we should have some complex business rules, but I'm uncertain that those rules would impact the VM tests of the RI significantly?

Composability - This one is a bit controversial, IMHO.  Not all M-V-VM frameworks have any focus on composable UIs... nor do I think they necessarily should.  We do have to showcase interactions between multiple views, but that's not necessarily the same thing (think two Window instances that interact).  Certainly we do not want to require a plug-in infrastructure. That said, however, it would be nice if RIs could leverage these concepts.

Blendability - RIs shouldn't "have" to borrow XAML, though I expect they will.  But keep in mind that "borrow" in this case is in the copy-paste sense, since RIs are almost certainly going to have to modify the XAML to fit within the framework of the M-V-VM library being used.  We can't control the how much an RI modifies the XAML files.

Persistence ignorance - A client/server or distributed system would put a heavy burden on the ability to run a RI, unless the server portion is actually available from the Internet. For example, if we use an existing web service, such as Twitter (not that I'm recommending Twitter) in a portion of the application. I don't want end users using an RI to have to setup and run a service just to run the RI. Even with an existing service, I think it should be possible for a user to run the application when they can't access the service.  So limited usage in an "optional" part of the application would be best.

On the shared resources... I still think this is a very bad idea. We may want to provide both WPF and SL versions, and we certainly want RIs to be able to be built in either platform, but there should be NO requirement that an RI work with both.  If an M-V-VM library targets only one platform, we do NOT want to exclude them from being able to produce an RI.

For data access, I don't think there's any reason to have persistence ignorance.  VMs do data access through the M, which we will be providing. So they are already ignorant of the persistence.  Making the M ignorant of the persistence isn't helpful.  It complicates OUR work, and doesn't illustrate anything in individual RIs.  So, from an implementation point of view, I think it would be wrong to take on a dependency to any ORM, other than maybe Entity Framework, since it's part of the .NET Framework.

That actually should be another goal/requirement. We should not require any dependencies beyond the .NET framework.  The final RI will, of course, have it's own set of dependencies, but we should push any dependencies up to them.
Apr 15, 2009 at 7:19 PM
First off, let me say that I am very excited to see this work being undertaken.  This may expand the initial scope of the project, but I think it is important to build not only a quality MVVM reference app, but to provide a quality WPF LOB app in general.  For businesses and developers looking at using WPF or Silverlight for LOB applications the more quality guidance that can be provided the better. Showing how designers and developers can/should work together is important.  And there are an awful lot of development shops that don't have dedicated designer resources (*gasp*) so showing how they can take advantage of Blend, behaviors, etc. would be very helpful.

I would love to see this application become "organic" in that it starts with a set of common MVVM "challenges" such as have been enumerated above, and then as new questions and scenarios are presented they are built into the application (potentially using a TDD methodology so people can see how to wrap testing around the solution).  I think the documentation can then flow in a very logical manner.  I liked the CRM suggestion above as I think that give the app an almost infinite set of directions.

Just my 2 cents.
Bob
Coordinator
Apr 15, 2009 at 7:50 PM
The problem with making it "organic" is that this impacts the RIs, which we won't have any control over.  If an RI author fails to update his RI when we make a change in the "base", his RI is no longer usable as a comparison to other RIs that did update. What we come up with should be as static as possible.
Apr 15, 2009 at 8:12 PM
Testability - If we specify some rules related to the interaction of view elements, then the RIs can demonstrate unit testing the VM to ensure that those interaction rules are satisfied. Maybe the requirement that two Window instances interact satisfies this.

Composability - I can see dropping this one. My library has a really nice composability story, so I'm probably being selfish here. Again, two Window instances interacting is probably good enough.

Blendability - Agreed. Using the same XAML should not be a requirement of an RI. I retract my prior statement.

Persistence Ignorance - I think that this is one place where MVVM is clearly superior to direct data binding. The VM abstracts the data access mechanism from the view (as opposed to the old VB demo we've seen for over a decade). Maybe a smart client is too much of a burden, but I'd like something to point to and say "Try THAT with drag-drop data binding."

Shared Resources - Yeah, I guess that is a bad idea.

Dependencies on ORMs - Absolutely, we shouldn't force an ORM on anyone. But the RIs should be similarly ORM agnostic, if possible. They should allow the consumer to use the ORM of their choice (even if it is EF).
Coordinator
Apr 15, 2009 at 8:34 PM
@MichaelPerry1971 - I think you and I see what a VM is in a different light.  The VM to me isn't the place for persistence at all.  That's the responsibility of the M.

I expect our M to be a set of POCOs, which abstract the persistence requirements at that level.  RI implementers shouldn't be thinking about persistence at all.
Apr 15, 2009 at 9:17 PM
I see this project as being as complete as possible, with the model being well defined. The VM is the area of contention - this is where the implementers could have real fun, but I'd like to see a consistent set of rules that can be applied so that people don't end up being swayed by one MVVM app over another just because the developer has been cleverer with regards to the rules. The View, again, should be fairly well defined, but I would expect that the implementer has leeway to "improve" as they see fit.
Apr 15, 2009 at 9:22 PM
@wekempf, You're right. I'm thinking about the difference between database binding vs. business objects. Business objects are a prerequisite for MVVM (that's the M, like you said). They are not a direct benefit of MVVM itself.

OK, so where does that leave us? Have we identified a list of criteria for the application specification?
Coordinator
Apr 16, 2009 at 12:03 PM
I think we have identified the criteria.  The discussion is slowing down, without much new.  I'll let people continue throughout today as I compile the list from this discussion, and then I'll open the discussion up to what we think the reference application should be.  So, if anyone's been lurking or holding out, speak up soon.
May 5, 2009 at 4:25 AM
Looks like a great list so far, I'll add a few thoughts.

1. +1 on the asynchronous calls bit. When you are developing apps particular in Silverlight, this hits you in a big way. In MVVM the first thing you run into is how to get model data in to the VM. The reference app could show techniques for doing it outside of any particular pattern, and then implementations of the ref app would address it in the context of the specific pattern implementation.

2. Apps with multiple transactions in parrallel are signficantly challenging when it comes to MVVM. For example, a common scenario is I have an order application where I can have multiple orders open at the same time.  This raises a bunch of concerns.
    a. How do I handle displaying selected orders simulataneoulsy. Think of a list of orders, that when I select, will load up multiple orders and display each order in a separate tab / screen.
    b. How do I handle context-specific actions like saving the current order, undo, approval from a global toolbar shared by all order instances.
    c. How do I manage state for each of the specific screens.

3. Role based UI - Different roles have access to / see different elements.

4. Commits / Rollbacks of tranactional data.

Glenn


  
May 8, 2009 at 5:09 AM

I have created a MVVM framework for ASP.NET applications, which has Dependency Injection and Event Broker functions. http://aspnetmvvm.codeplex.com

Will you create similar things for WPF and Silverlight?