The native PRISM's modulariy mechanism support loading modules by path to assembly, containiтg this module. I want to have availability to store modules' views (XAML) in database in order end user could change and customize them. Database is chosen as it is simpler to store and retrieve information and requires no recompilation and making of binaries. The problem is that View consists of XAML and codebehind and we need to divide(?) them and store separately and when we need them we must clue them and load to module (with reflection or something else?) but I don't know how and if it is possible at all?
+1
A:
I see two options here. The easy way or the hard way.
The easy way is to have all the assemblies on the drive, and have a PRISM module catalog that loads them depending on settings from a database.
The hard way is to put the assemblies into the database, and have the module catalog load the assemblies from there. You'd have to encode the assembly, probably using Base64, put it into the database, and then reload the assembly from the database.
To reload an assembly from a database record, you can use the same mechanism as the DirectoryModuleCatalog. Copy that class and change it so it loads the assemblies from the stream coming from the DB instead of a file from a directory.
Cameron MacFarland
2010-01-21 10:52:33
Two ways that you've advised differs from each other only by the place, where dlls are stored - in filesystem or in database. In both cases user need to change XAML in sourcecodes for dll, recompile it and put again in database record instead of previous version of dll. This requires user to use Visual Studio for editing and aware of recompiling dlls. I wanted to free him from these duties for its simplicity. If he could only edit XAML in database and then app dynamically loaded it (using Xaml Reader i suppose) into the module.
Andrey Khataev
2010-01-21 11:54:21
Oh I see what you mean. I'm assuming you put some sort of config screen in your app to allow the user to turn on/off modules, and that setting is stored someplace, probably the DB. Did you want more customization than that?
Cameron MacFarland
2010-01-21 12:09:19
Yes, I want end user could change XAML of views that stored in modules and these changes being applied on a fly without recompiling dlls
Andrey Khataev
2010-01-21 12:12:46
@Andrey Khataev - Why would you want to avoid giving the user an editor designed to edit XAML files? I think this is more tying the users hands than helping. Basically now you are allowing them to change files that might not compile or be syntactically correct and integrate them into the application. I find this approach troubling. You are removing a lot of the checks a precompilation and sanity check gives you. I'd urge you to reconsider. Moving code out of a DLL does not make it more "configurable", it makes it more error-prone.
Anderson Imes
2010-01-21 23:44:26
1st - I suppose to have an editor for XAML, but for now - only pure XAML; 2nd - Could you advise Visual Studio or Expression Blend like editors but more lightweight, where I can make dlls?
Andrey Khataev
2010-01-22 07:48:17