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

Is having multiple assemblies an issue?

Feb 16, 2011 at 1:55 PM

I had a good discussion online about the Core vs. Framework. The known naming issues (plural, not plural, etc.) aside, it is really annoying to have two assemblies?

My thought is the separation of interface and framework means you can mock and test your view models without having to pull the entire framework over. However, it may only make sense internally to Jounce to do any mocking/testing and therefore these should collapse into a single. I'm happy to do the merge and turn the whole thing - core, framework, regions - into a single DLL, but wanted to get the consensus of those using it first.

Should be backwards compatible because the namespaces will be preserved (but if I fix the viewmodels vs. viewmodel, etc then it will break).

Let me know your thoughts - thanks!

Feb 18, 2011 at 2:44 PM

Hi Jeremy,

I thought I was the only one thinking about this. It looks lilke there are others. Yes, ideally you only want only one assembly because this is the unit of reuse. Also, if you want to customize the library you would do it thru another assembly called Jounce.Extensions such that upgrades are easy to manage. If you add the mocking, testing assembly, that's one extra. In general, I'm all for: "Less is more". Again, that's my preference: one Jounce.Framework. It would be nice for Codeplex to offer polls...:)







Mar 3, 2011 at 2:49 PM
Edited Mar 3, 2011 at 3:13 PM

Hi Jeremy,

as long as there are only a few assemblies involved I don't see separation as a big issue. I'd even buy your reasoning about keeping a separate Core assembly for testing purposes if it included the ActionCommand and BaseEntityViewModel classes.

Furthermore, the Regions feature is largely optional and keeping the Regions assembly separate would make perfect sense if you want to minimize memory/download footprint. Same goes for the testing assembly, of course, and likewise for any other "optional" feature.


P.S.: And please do straighten up the namespaces even if you keep the assemblies separate :-)