Modularity about prism

[Mike-E-angelo]

Haha... well alright then, since you are still with me on this... we might as well finish the discussion from #1, then, because I have a lot to say and I am really kicking myself that I gave up so easily. ;)

Your assessment of the "overly-complicated" approach that I take just so happens to be an extension of the exact same approach that is perfectly validated by years of use in an existing system (WPF), just brought over into another (non-visual) component of a client application. It's exactly the same approach as WPF, just non-visual. So, I am curious if you also find that approach overly-complicated/over-architected in WPF, as well. And if not, then what the difference is?

And speaking of non-visual, I would also like to remind you that the System.Windows.Application object is also defined declaratively in markup as well (and in this case, actually references the very non-visual component in our discussion). This approach is simply an extension of that.

With that said, I am interested in knowing if you also consider declaratively defining System.Windows.Application overly-complicated and architected as well? You could easily define all of its properties in a .cs file. Why don't we do that with our applications? For all intents and purposes the System.Windows.Application is the original Bootstrapper.

And as for that Bootstrapper, one could also make the case that it itself is "overly-complicated" in its own right, as it has so much concern within it. That is, it deals with so many different areas and is so tightly coupled with so many different classes, that it can be seen as breaking the the single-responsibility principle. This is especially so when compared with my alternative, which simply uses the commanding pattern to cleanly encapsulate logic and limits execution to a particular, singular concern per command -- exactly how it is done (or supposed to be done) with WPF commands. In fact, since the ICommand (surprisingly) exists in our PCL profile, I removed the IUnityConfigurationCommand altogether and am exclusively using the ICommand now. Furthermore (as we've discussed), this is all defined declaratively via Markup, which is designer-friendly (THE reason why System.Windows.Application is defined in Xaml), putting the cherry on top (in my view)... AND making it consistently defined like every other element in a WPF client application.

You know, I just feel like I have to say that just because no one has ever thought to define a Bootstrapper in a declarative manner (like everything else in a WPF application), that it doesn't make it a terrible idea. ;)

So I guess I am curious, since you are standing by your assessment (which I obviously respect), if you still consider my design overly-complicated/architected now that I have better explained it (and simplified it with a better intention-revealing/familiar ICommand)?

...at least, I hope (and feel) that I have. 😛

[Mike-E-angelo]

After looking through the code there are really two concepts here:

1. Modularity: definition and organization of modules within the domain of a running application that can be used to define application components (that is, candidates for loading and processing types within assemblies for features/functionality in an application).
2. Dynamic Modularity: loading additional modules after an application has loaded.

I would like to suggest that the first concept is universal, and the 2nd is platform-specific. Basically when an application is loaded, it consists of x-number of assemblies, but only y-number are really deemed specific to that application and should be considered for activities such as convention-based registration, etc. I hope this makes sense. My framework does something like this currently, but it is not as strong as what I feel Prism could offer in this regard.

Essentially what modules do is say "these are the core feature-specific assemblies of my application, and here is some additional metadata/information around them." Denoting these modules (and their associated assemblies) makes it easier (and faster) to find components, as they represent the core subset of assemblies being used for application feature use. It's like there is Domain-Specific Language... I want to say that there are application-specific assemblies as well. :) That is what I am pawing at with this ask.

[Mike-E-angelo]

Well, I can't believe I did this, but I did manage to find and compile a somewhat halfway-compiling version of my framework from about 3 or 4 years ago. It's Prism 4.1-based and is chocked full of cool functionality.

Here is an example of a module that I was talking about earlier: Welcome

Every module assembly has:

• Module Entry Class - Registered via MEF.
• Configuration - This is defined in the entry Module class and is where all the magic happens. It has all the commands used to register any action needed for the module to operate. So for instance, registering a view with a region and so on. I managed to make a cool navigation registration mechanism, which you can also see in this file. All the views required for the module are defined here.
• One or More Views - All the goodness you expect from Xaml.

You can also see that an Icon is defined in the assembly that is used to display a visual cue whenever the module is referenced throughout the application. This obviously will have to change in a cross-platform context, but it's interesting to see here.

I am showing this all off as this project never really went anywhere, so I guess I want to get some ROI on my work somehow. :) Plus, it is good to see from a project perspective how your product has been used and how it can be used going forward.

[brianlagunas]

Modularity is something that we have discussed, and will continue to discuss. When writing mobile apps, we have to consider a number of factors, such as size and number of references, performance, battery impact, number of processes, etc. Also, in Forms, there is a major limitation with references not being loaded in the app domain unless there has been a static call, or direct reference to an object in that assembly.

I'm not saying we will never add Modularity in to Prism.Forms, but we will have to really look at the benefits and feasibility of doing so. For now the plan is to wait and see how the Xamarin.Forms platform matures. We also have to wait and see what is going to happen with WinRT. Hopefully we will know more after the Build conference about Windows store and Phone.

We will also need to look at how the majority of Forms apps are built to see if this is something that at least 80% of Forms devs would even use or benefit from. It may turn out to be overkill. Then again, it may turn out to be the best thing since sliced bread.

[Mike-E-angelo]

Sounds great, Brian. Thanks again for your excellent diligence and engagement. I, too, am very much looking forward to build to see what MSFT and Xamarin have been up to and will propose for the next year or so. It's 7 weeks from today, actually. :)

[Mike-E-angelo]

FWIW, I have been checking out a few articles, and it does indeed appear we are in store for some disruption in regards to vNext:
http://blogs.windows.com/buildingapps/2015/03/02/a-first-look-at-the-windows-10-universal-app-platform/
http://blogs.msdn.com/b/bethmassi/archive/2015/02/25/understanding-net-2015.aspx

I especially like this overview:

Looks like Xamarin.Forms (and other "App models") will fit in nicely, although exactly "how" remains to be seen. It is also noteworthy that a lot of the disruption from .NET Core will be mitigated if you are already on PCLs, but this is all still good to know from a preparation/awareness standpoint. 👍

So essentially (to add to what has already been said), "Commit Carefully" until April 29th. :) Thought of this thread and had to share.

[brianlagunas]

Thanks for sharing. This is exactly the reason we are being so cautious with what features we start porting over at this time. It really is a "hurry up and wait" situation.

[Mike-E-angelo]

You said it. It is indeed a holding pattern. If you don't mind, I will update this thread with relevant bits I find. If not just let me know a better place (or tell me to shutup all together. ;)).

Xamarin just announced Windows Store Preview support today: http://blog.xamarin.com/xamarin.forms-for-windows-store-preview-and-xamarin-for-oss/

I will be spending some time checking that out for sure. I also applied for their new OSS subscription. You should too if applicable. :)

[Mike-E-angelo]

OK... I am looking into DirectoryModuleCatalog right now, and I just want to verify something. This would probably be better-suited to CodePlex's forums, but it wasn't until I found the following article through some searching that I decided to post here...

http://brianlagunas.com/prism-dynamically-discover-and-load-modules-at-runtime/

👍 :)

My question is simple: It appears that the DirectoryModuleCatalog only loads in IModules from assemblies that have NOT been loaded in the current domain... is this correct? If this is the case (and running unit tests on my side confirms this), this seems sort of backwards to me, as it seems to me that with a Directory module catalog I am going to point a module catalog at a directory and it is going to pull all the IModules out of all the assemblies in that directory. I believe this is how the DirectoryCatalog also works this way as well for MEF, which is leading to my expectation. I guess all the "in memory" IModules are expected to be added via manually or via MEF.

As an aside, your dynamic monitoring catalog makes much more sense (read: provides much more value) and it is something we should have here in Prism 6 if possible, IMO.

Any clarification/verification would be greatly appreciated! Thank you in advance.

[briannoyes]

This is a limitation of .NET, once an assembly is loaded there is no way to unload it unless you restart the process or load it in a separate appdomain, which opens up a whole separate can of worms we decided not to pursue back in Prism 1.

[Mike-E-angelo]

Thank you for your reply Brian, but it sounds like I didn't explain myself very well. I understand the whole appdomain load/unload, and it's a good solution. My confusion is around the fact that I am pointing a module catalog at a directory, and it is only loading IModules in assemblies that are not already loaded in the current domain. It seems to me that it would load ALL assemblies found in that directory (whether they are already loaded or not in the current domain) and parse them for any IModules -- much like how MEF works with a DirectoryCatalog. I hope that helps clarify what I am trying to say.

[Mike-E-angelo]

BTW, if there happens to be any interest around this, I now have a pretty significant change to the Modularity functionaly in my fork at the moment. It's actually quite a bit more than just Modularity, in fact. Unfortunately, I am afraid I am a bit of a bull in a china shop when it comes to Git, Merging, PRs and the like, so I will need some assistance with anything we do with it (assuming you are interested in my changes). I am not sure if it is possible to PR a select portion of code. All of my experiences with GitHub have been all-or-nothing when it comes to PRs. I have been merging with your primary branch, so there's that.

Essentially, I have accomplished what I wanted to do with Modularity, which is to have it as a baseline feature in Prism that is extended to different platforms based on need. I have the base ModuleInfo in the PCL, and then also have the dynamic-loading ModuleInfo (called DynamicModuleInfo at the moment) in the WPF library. I also spent some time really cleaning up the DirectoryModuleCatalog (ok it ended up being a straight-up massive refactor 😇) as it was comprised of multiple concerns that I felt were better placed in multiple, smaller classes.

It is a lot, and I am sure I have violated many community rules/protocols (it would be nice if you had a ReSharper code style formatting template, btw :) ), but I just wanted to see if it might be possible to review, even though you've already said no, haha.

If by the remote chance you would be interested in my changes, I am definitely willing to work with you make sure it is in a state that makes sense for your project. Otherwise, if I've already passed the point of no return, I am definitely OK with that as well. Just let me know what the next steps are in any case.

FWIW I am really a newb with Git and all the new world of source control/forking so this is really the only way I am going to get good quality practice and experience. :)

Thank you for any consideration and feedback!

[briannoyes]

When it comes to the long standing, stable code of Prism that in use by thousands of companies, I don't think we would even entertain bringing something like that back in just to "clean it up" unless there was substantial improvements and new functionality making it worth the risk that fit within the roadmap that we have for the main code base of Prism. And for us to even review it, it will need to be submitted as a pull request with 100% unit and acceptance test coverage (like the existing Prism code base has).

So you may just want to consider keeping your fork out there as a public fork and document well what you think it does that we don't and get a following around that yourself. If there is a significant interest from others then we could consider bringing it in more strongly.

[Mike-E-angelo]

Hey sounds good to me @briannoyes... I just had to get it out of my head so it wasn't rattling around there any more. Thank you for your thoughtful explanation and your patience in dealing with my enthusiasm for your project and my naivete with Git-ness all around. :)

[brianlagunas]

Michael, I want to go back to your DirectoryModuleCatalog question, as I don't really understand it. The DirectoryModuleCatalog will search for all assemblies that exist in a directory for classes that implement the IModule interface and load all of them. So I am not sure what you mean by "... only loads in IModules from assemblies that have NOT been loaded in the current domain". It will load all assemblies in the directory. The link you posted is a modification to the DirectoryModuleCatalog that allows it to monitor the directory for assemblies being added after the application has been run. So when a new assembly is dropped into the directory, it will be loaded into the application automatically during runtime.

[Mike-E-angelo]

I thought so too... but this line appears to remove all assemblies that have already been loaded in the domain, leaving only the ones that have not been loaded. Do I have that completely wrong?

[brianlagunas]

Oh I see what you are asking. First off, an assembly can only be loaded once into each AppDomain. The CLR doesn't support the concept of having two (or more) copies of an assembly in a single AppDomain. If you did by chance try to load the same assembly twice, the already loaded assembly would be returned. So this line of code protects the developer from themselves. If they were to load "AssemblyA" using a different module catalog (don't forget you can get modules form many sources), then that line of code would prevent any issues from arising. So we make sure we are loading modules that have not already been loaded.

[Mike-E-angelo]

Exactly. So my understanding is correct. This is different than from a MEF CatalogDirectory where you point it to a directory and it processes everything in that directory, regardless of whether or not it is currently loaded in memory, correct?

I am thinking here that it should be named differently because of this discrepancy/difference. Just a thought. I spent a lot of time in the code yesterday (even though it's documented!) really trying to understand this and doing a bunch of double-takes. But, that's usually me anyways. 😛

Along such lines, the documentation currently states: "The directory catalog will scan the contents of a directory, locating classes that implement IModule and add them to the catalog based on contents in their associated ModuleAttribute."

It should say: "The directory catalog will scan the contents of a directory, locating classes that implement IModule in assemblies that have not been loaded in the current AppDomain and add them to the catalog based on contents in their associated ModuleAttribute."

Perhaps additionally it should also state: "It is assumed/preferred that IModules in assemblies already loaded in the current AppDomain will be located and added via different module catalog(s)."

Correct?

[brianlagunas]

MEF automatically handles the assembly loading to not have collisions in the same AppDomain. The CLR does not allow the same version of the same assembly to be loaded multiple times. We are doing the same thing that MEF is doing. The naming does not need to change. The DirectoryModuleCatalog succinctly describes the purpose and functionality of the class, and we do not need to rename it to include implementation specifics in its naming. Keep in mind, Prism has been around since 2008, and is being used by many thousands of companies and in even more applications. This has never been an issue, and documenting how the CLR handles loading assemblies in AppDomains is not something we should be concerned about.

As far as a developer is concerned, when they put assemblies in a directory they will be loaded. Event if they mistakenly have "AssemblyA" in a different catalog, the mistake is transparent to the developer and the end-user of the app, because the app will just work as expected.

[brianlagunas]

I would also like to mention that I know it seems like you have been getting nothing but push back on every idea you have presented, but don't let that discourage you from continuing to participate in our community.

Keep in mind that we have a very large user base that we have to consider with every change we make. We have to be very careful of every change we make, and challenge every choice to make a change. We don't mind making breaking changes, but those changes must have an obvious benefit to our users or align the product with our vision of where we are going to take Prism.

Right now, your ideas are very grand in nature, and would require a lot of code churn in our already mature WPF code base which is very risky. We can't introduce that risk to our customers that depend on Prism for the mission critical enterprise LOB applications.

I hope this sheds some light on our decision process when evaluating new features or code changes.

[Mike-E-angelo]

Haha, nope not a problem at all (but thank you for mentioning that). While we are on it, my only suggestion going forward is that you please don't ever call anyone's code over-architected/over-complicated ever again (O-U-C-H 😉), no matter how much so it may seem... and especially when it is utilizing/extending your product. :)

For a little background on myself: I have yet to launch a single application or product in the current modern public/consumer space/environment (it's been all private LOB implementations, and the last "successful" thing I did was a gaming website network in the late 90's, sigh), nor have I ever maintained an open-source product with any sort of sizable userbase, so I am completely understanding (and appreciative) of your viewpoints and explanations.

Now, as for the DirectoryModuleCatalog/DirectoryCatalog problem... I did some poking around and you are indeed correct, DirectoryModuleCatalog does exactly what the DirectoryCatalog does. The reason for my confusion is that when I created the CompositionContainer, I also added AssemblyCatalogs for all assemblies already loaded in memory, as well. #doh. That is why everything always "just" worked and I had an inaccurate perception of how the DirectoryCatalog operates.

So, sanity restored... for now. 😛

[brianlagunas]

Sorry, I can't take that advice, especially when its a customer using or extending a product I am responsible for. I have to call it like I see it or that wouldn't be doing anyone any favors. I try not to let my customers shoot themselves in the foot if I can help it. May I suggest that when someone calls an approach over complicated, don't take it personally, but rather re-evaluate the approach being taken. Chance are, there are some merits to the comment. Especially when it comes from the team that owns the product you are using or extending.

My 2 cents. Take it for what its worth.

[brianlagunas]

While I would love to address each and every one of your concerns regarding why I think trying to configure a Prism application using nothing but XAML is a bad idea, I would rather do other things with my very limited free time.

Not everything in WPF is done declaratively in XAML, so trying to support your position by implying that it is, doesn't help your cause. XAML has its place, but this is not one of them. Don't assume you were the first person to ever think about a declarative bootstrapper.

But, that's the beauty of open source. While we will never do this in Prism, you have the complete freedom to spend the time and effort to do whatever you want to our framework in your own fork.

To end this conversation I will say, it doesn't really matter what I, or anyone else, thinks. Just work on what gives you enjoyment, and if that's writing a framework that lets you configure Prism apps in XAML, go for it.

[Mike-E-angelo]

Very well, then. I accept your apology. 😉

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.