This project has moved and is read-only. For the latest updates, please go here.

What do you want in 1.0?

Nov 11, 2010 at 4:14 PM

Jounce is starting to be adopted in many large projects and I've corrected a half dozen bug fixes based on the feedback and my own use.

I really only released it as alpha because I wanted to get some third-party use and stabilize any issues I might be missing.

I'd like to open up discussion to see what the people here will want from an official 1.0 release. I could release now with the fixes rolled in, or wait for some more features. Regardless, it will be 100% backwards compatible with the 0.9 beta release.

Let me know if you think it makes sense to release now with the issues stabilized, and to follow up with later releases to address things like RIA services integration, etc, or if there are some "must have" features you think it will be a waste to do a release without.


Nov 12, 2010 at 1:32 AM

Hello Jeremy,

Our application uses WCF RIA services extensively, hence RIA services integration would be a nice addition.  Do you have specific features in mind?

F. Thornton Boulware III

Nov 13, 2010 at 5:43 PM

Hello Jeremy,

Thanks for this brilliant frame work.

Please do release  version 1.o along with a full documentation with examples using EF. And later on you can give more features to the Jounce.

Have a nice day



Nov 19, 2010 at 1:25 AM
Edited Nov 19, 2010 at 1:53 AM

Hi Jeremy,

Great work. I've started to use the framework at work on a project . A couple of points:

- Is there a reason why the View is not a Control instead of UserControl. On the same topic I have a ChildWindow which is a view and I had to hack the framework to a) allow ChildWindows to be exported as views and b) run Show() before activating the view in the ViewModelRouter. (Do you have another implementation for this, maybe thru a ChildWindow region adapter, but force the region to show up before the view ?) I had another try using the Popup control but it's tedious.

- I've separated the JounceHelper into 2 classes - to be more easily understood: ThreadHelper which runs the action on the UIThread and ViewHelper to convert the view name into an argument type.

- Do you have any samples on how consuming services would be done thru the use of workflows?

Thanks again for the project,



Nov 29, 2010 at 12:54 PM

I'm exploring the view as a control, that has been requested multiple times so just making sure there won't be any negative nuances to doing it that way. The ChildWindow is a special case because it's not an ordinary view and I'm mixed about including it because it behaves so differently. Any thoughts on the way it would make sense without trying to force something awkward on the existing interface?

The quick start part of the source download shows many work flow examples, but I can look at some specific service ones as well. You basically can use the event class if you are doing the event model, and register the completed event to called the invoked, or you can use the action class if you are using the APM.

Feb 2, 2011 at 3:49 PM

Jeremy, I've just started looking into your product and I'm very interested in using it. However, the most important thing is, WCF RIA services integration. How long do you think it would take before that is completed?

Feb 2, 2011 at 5:25 PM

Bottom line: RIA Services is popular, it looks great in drag and drop demos and makes it easy for small projects but I've just run into too many problems and had to resort to other technologies to embrace it directly. I don't doubt it will gain some legs in the future but the same reasons this developer chose IdeaBlade's DevForce over RIA Services is why I almost always end up using a different data access strategy:

I also don't believe data access being intrinsicly mixed in the MVVM framework. The MVVM deals with the concerns of synchronizing views and coordinating calls out to other services - and should be independent of whether those services are mocked data, isolated storage calls, WCF service calls, or RIA services.

Therefore, I doubt I'll ever directly support RIA Services with Jounce (just like Jounce doesn't hook directly to WCF or Sterling or DevForce or anything else). Jounce doesn't keep you from using RIA services at all, and that is what I'll focus on is some quick starts and guidance showing how to use the two together, similar to the navigation framework, but a direct interaction would force a lot of developers down a path they don't want to go down. Like region management, when RIA matures I can see a satellite assembly i.e. Jounce.RIAServices that provides additional features there but again, to me, supporting it would be almost like a recommendation or a suggestion and I don't agree that RIA is the best way to go. Like Data Entities for ASP.NET and some other fast tools, I think it's an easy way out that demos well and works fine for smaller applications but I've yet to see a painless enterprise scale implementation that relies on it heavily. Most of the time they end up having to customize and change things to the extent that it is about the same amount of work as having a home-spun DAL instead.

I'm always open to suggestions and may change my mind but I'm just waiting to see a strong compelling reason to do it, and haven't found that yet.

Feb 2, 2011 at 5:43 PM

Jeremy, Your points are [very] well taken and I hear you on the RIA's strength. I've spent some time on DevForce and no doubt it is a mature and deep product. In many cases, or most cases (I can show you every contract job requirements), clients insist on WCF RIA Services, EF4, Prism4. They just want to stick to MS offering to feel secure, so you get challenged as soon as you mention third party product.

You mentioned "I've just run into too many problems and had to resort to other technologies to embrace it directly", what other technology beside RIA and DF do you use that will take care of middle tier pluming?

Secondly, in another post you had mentioned "Busy, busy, busy" :-), with your busy schedule, what's your commitment behind Jounce? I like your Stirling and Jounce and I want to make that as a solid offering to clients. But many Open Source, free product end up undeveloped after the initial version is out and the author goes on to something else. Then we have to yank everything out and start with another product. Been there... and wasn't fun.



Feb 2, 2011 at 6:25 PM

All great points!

We often have customers request RIA as well because that's what they've seen, but typically we can make the case for something a little easier (in my opinion) to produce/maintain and scale. I typically don't use a "product" but keep the traditional separation of tiers. On the server side it could be ADO.NET, LINQ to SQL, LINQ to EF 4.0, NHibernate, etc. This has a layer of abstraction to send it over the wire as a POCO, so Silverlight no longer cares what the underlying technology is, only that it is manipulating domain objects and sending them back. I've wired it this way for RIA, too, but instead of the abstraction happening before the WCF end point, it happens on the Silverlight side. I like POCOs because you can share them directly between the Silverlight and server side. They can be passed right into a VM and used to back the transaction. When sent back, a layer simply needs to decide what to do to map it back into the data access strategy. For very large projects then tools ranging from generators to templates helps automate any monotonous tasks.

Biggest advantage too is the dependencies go away. RIA cross-cuts concerns and you are explicitly tied to it. With a cleaner separation, I can develop completely independent of ever writing a service or even a data access layer. I code to the objects and mock it. In fact, in a recent Microsoft project this approach allowed us to completely mock the service layer. If you were on the Microsoft network and could access the service, great. If not, no problem, flip the switch and mock the data and still get a running, interactive version to work with and test. I just don't know the equivalent flexibility with RIA or even how to unit test that. In most cases I've found this to be FASTER even if it involves more code because it promotes more parallel development, and the isolation also means that changes to the database don't require a refresh all of the way through, only those properties that need to round trip to the client.

As for commitment, you make a very good point. That is why I chose the license I did for Jounce - literally an "anything goes" license so you can steal the code, modify it, own it and not ever worry. There is certainly the issue of version parity but the option is there to just run with it. The idea is for this to be a tool to provide a reference to solve common problems, but to teach you enough that you don't have to rely on the framework as a black box and can solve new problems when they come up.

Jounce will get love but you are 100% correct in that I cannot make any specific commitments. There may be stretches of months where I'm not able to touch it, and other periods where I develop quite a few features. Fortunately, as is often the case with open source projects, both Sterling and Jounce have taken on a life of their own. I now have many developers in the field using them and offering their own submissions to help support and contribute. I suspect eventually the projects will grow to be bigger than just "me" and at that point will have more commitment to a longer life time. Right now you are correct to say the releases are at the mercy of my time, but I continue to integrate features (like the visual state aggregator) as they make sense in projects or solve problems that aren't yet addressed by the framework.

I also don't want to imply I'm completely anti-RIA services ... but I do believe in a clean separation. I think the instant the Silverlight client is dependent on the data access strategy, we've suddenly created coupling that causes instability. So when I do use RIA it's with a layer of abstraction that often ends up not buying me much more than if I simply translate an Entity Framework class to a POCO over the wire and back again - with the added advantage that if LINQ to Whatever comes out and is better, I can swap to that without refactoring my entire client, I only need to rewrite the DAL.

Feb 2, 2011 at 6:38 PM

I love people who give straight answers to questions rather going in circle.

Thank you my SL Insider colleague.


Feb 6, 2011 at 12:13 AM
Edited Feb 6, 2011 at 12:28 AM

My vote is to keep it the way it is.  I think you've achieved a framework that is extensible, MEF-able, and lightweight.  Offering dynamic XAP downloading, regions, and the EventAggregator are exactly what I needed to add to my own custom-rolled MVVM framework, so just extending Jounce with some of my own existing functionality became a no-brainer.  I think it's perfect the way it is.

That's not to say that I won't throw out a request a month down the road once I become a bit more familiar with Jounce (assuming I can't just extend it) ;)

Thanks again for saving me weeks worth of development and testing!

Feb 14, 2011 at 4:26 PM

Thanks for all of the feedback, everyone. Here is the game plan:

Finish fluent configuration (add regions).

Add view model lifetime control (i.e. for cases where you want multiple instances of the same view model)

Add a quick start showing EF/RIA Services.

Once I get those three (we're talking probably end of March based on my current work load) I'll go to 1.0 RTM for Jounce. Was hoping to synchronize it with Sterling but just didn't happen.

Mar 3, 2011 at 12:46 PM

Great to hear all this. Jounce soon to RTM!

We're using Jounce for an internal usermanagement app ( membership + custom profile extensions) and I found it a very great help; easy to use and it was a great learning experience.

I really like to see the new quick start showing EF/RIA.

Also a quickstart on how to implement a service like Sterling for authentication/authorization is something I hope to see soon.

Anyway, great work, great learning resource and keep up the good work!

Mar 3, 2011 at 2:28 PM

Great to hear this indeed!

jeremylikness wrote:

Thanks for all of the feedback, everyone. Here is the game plan:

Finish fluent configuration (add regions).

Add view model lifetime control (i.e. for cases where you want multiple instances of the same view model)

VM lifetime control sounds like something I'd really like to see in Jounce. Being confined to an effective PartCreationPolicy=Shared for View/ViewModel ensembles is about the only real restriction I've had to deal with since migrating to Jounce from the framework I used previously. All other facets presently covered by Jounce pretty much fit my scenario like a glove or had obvious extension points to make the fit.

Just to get things right: Will it be possible for a View to specify via its ViewModelRoute if it gets connected to a shared ViewModel instance or, alternatively, to an individual ViewModel instance not shared with any other View of the same type?

And if you're still accepting wishes:

  • Would you mind making Jounce CLSCompliant?