I have a growing WPF solution where I have multiple projects within.
I have one main "module-selection" project that acts as the entry point when launching the application. From this one I typically load one or more of the "module" projects.
I have several "module"-projects that are quite big and are currently set up as class libraries.
At the bottom I have a common resource project where I keep and maintain all resources that are common for all the modules (typically themes, colors, control styles)
When everything is in one project you can define your global resources in the app.xaml. When you have resources in class libraries I believe this works as well run-time, but not design-time. The workaround is linking in the resources from every control or page that needs it. This latter solution works, but will then spend time loading the resources everywhere you define it and this impacts performance significantly.
What is the best practice to achieve dividing your LOB application into multiple projects while maintaining global resources in an proper fashion?
Related
I have a WPF application that uses a layered architecture with three conventional layers: User Interface, Business Logic, and Data Layer. Now I have a requirement to split the application into vertical slices by functional areas (e.g. Customer, Product, Order). Meanwhile I would like to keep the horizontal layer separation within each vertical slice.
I am considering to use the PRISM modularity framework to accomplish this. So each functional area (vertical slice) will be represented as a PRISM module. But since my modules have a layered architecture, each module may consist of multiple assemblies.
Based on the PRISM documentation the ModuleCatalog assumes that each module is in one assembly. I am not sure how I can group multiple assemblies as one module. Any ideas if this can be done?
Edit -- I missed to mention that I want to de-couple the layers by not directly referencing the implementing assemblies for the layers. Instead I define the interfaces in an interface project for the respective layer such that only the interface project is referenced by the layer using it. Given this I still need a way to tell a module about the implementing assemblies for its layers.
You're over thinking it. Your other assemblies will just be references in your Module project. You will only add the module to the ModuleCatalog, and as long as you have your referenced assemblies in place it will work as expected.
I'm trying to figure out what would be best solution to the problem I'm facing. I have a Silverlight application which should be composed from different modules. I can use Prism, place regions and load modules and fill regions with loaded modules but this is not enough in my situation. Here's what I want to accomplish:
For most views that gets loaded from different xap files, I should place an element somewhere in the shell, which will perform navigation to the dynamically loaded view.
That element (which links to dynamically loaded view) should support localization and should have dynamically assignable data templates, different module links should have different content/data template (I'm thinking writing data templates in xaml files on the server and reading them from silverlight via XamlReader, maybe there's a better way?).
Uri mapping and browser journal should work with navigation. Silverlight default navigation mechanism better suits my needs than the one found in Prism.
The architecture should support MVVM.
I think thats all. I just couldn't think of a good architecture which will satisfy all my needs. Any help would be greatly appreciated.
I do not know of a single product/solution that would cover all your requirements, so here are some comments on each:
If one area of the shell has a region that supports multiple items, you just register a control of type link/button etc with the same region name in each module. For example we register views based on the Telerik TadRibbonTab (instead of UserControl) with a region named "views" which is a RibbonBarTab with a region named "views". Every module then adds its its own button to the list. You can do the same thing with any multi-item container.
Localisation is a completely different issue and can be solved in a number of ways. See my answer here: Load Resources ".resx" from folder in Silverlight
A custom navigation mapper can be made to behave like the standard one, without messing up the support for Prism regions. The one we created encodes GUI information such as current selections (current view and item selections etc) into the URL. That means we are in total control of the state and the URL controls the state.
Hardly anything stops you using MVVM as that is one small feature for separating views from code-behind data.
I will be interested in what other solutions are proposed as we are always looking for new ideas too.
So far I have been creating Silverlight apps with all logic crunched into a single xap file. But as the application grows in size,
I seriously think I should break my Silverlight application into smaller multiple independent applications.
I would like to know how others solve this increasing size problem??
If you're looking to make some changes to your application, by refactoring it and splitting out parts, consider all of these.
Custom controls get their own control assembly
Definitely create control assemblies for any custom controls you develop. Not only do you get the benefit of self-contained controls, and optional use in your current and future projects, you can
take advantage of default control styles
use the cached assembly feature with them
share components with other projects
invest in your core code and controls, instead of investing in cleaning up application logic (if you're using static or style analysis, for instance) - spend your time where it will make the most impact
Consider dynamically loading new assemblies
There are some methods available for dynamically loading additional code into your app domain, it may be possible to abstract out less-often used parts of your app, and use this to load in those components. This is a more complex and involved app, but it can improve start-up performance.
It'll take time to split out the code into other assemblies when you're looking at a large application, and testing it can be a challenge. But you can end up with "sub-pages" and parts of your app being loaded only as needed.
Taking the time to design a system to load in new functionality and parts of your app, and architecting this framework, can take time to do right. This typically is using AssemblyPart to load a new assembly that you can reflect into and instantiate new objects from.
Merged Resource Dictionaries
Resource dictionaries can allow you to store styles, control templates, and other resources outside of pages, and outside of your App.xaml.
Cached Assemblies
Once you move to Silverlight 3, you can use the cached assemblies feature to store individual assemblies outside your .Xap, alongside, on your server - and as a bonus, those assemblies will be cached on the machine for quite some time.
A resource diet
Are you really using all of your graphic assets, XAML, controls, string resources, etc., that are stored inside your XAP file? Audit it from time-to-time and make sure you're getting the most bang for your byte.
A splash screen
If you're simply trying to improve the performance (download time) for your application initially, consider creating a splash screen. The Silverlight Toolkit samples have one - it's a simple Silverlight page that will load and display while your .Xap downloads.
Remote graphics
Instead of including image resources right inside your application/XAP, move your images to your CDN or server, so they can be loaded only as needed. This is often a nice and quick win.
Simplify your app
Make sure you actually need it to be XAML-heavy, graphic-heavy, etc. Maybe it can be simplified!
You should distribute your Silverlight modules using PRISM or MEF frameworks.
Visit http://mef.codeplex.com/
I'm having a little trouble as I decide how to structure my projects. This question is slightly subjective, but I'm having trouble conceptually.
If I create a wpf blend project (sketchflow right now), it creates two projects, "Project" and "ProjectScreens". Is this the best layout to use?
The issue is, I have classes and code (networking, file i/o, etc.) that I need to reference within the screens (i.e. they click a button, it creates a network connection), and the core code needs to reference the screens. This creates a circular dependency.
I've tried merging them all as a single project, which works, but it stops becoming a sketchflow project at that point.
I guess the big thing, what's the best way to structure this with my core code and my sketchflow prototype?
Check out the Model-View-ViewModel design pattern. You'll find it fits well for WPF (and Sketchflow) projects because it keeps your business logic independent of your UI and supports the binding-oriented development model of WPF.
The SketchFlow project is separated into 2 assemblies so that you can do all of your work in the screens assembly, and then later re-use what is in the screens assembly elsewhere if you want.
The main project is a very simple wrapper that enables the use of the SketchFlow runtime player.
I have a PRISM based silverlight solution under source control. In regards to theming I have a project for each theme, for example 'Theme_Summer', 'Theme_Winter' projects. In reality there may be over 30 of these theme projects. Each theme project contains a selection of resource dictionaries to hold the styles etc along with the images, sounds etc that are required.
Each of these projects also has a Main.xaml merged resource dictionary that ties together all the resources in that theme project. My main application then just uses the Main.xaml resource dictionary from whatever theme project it needs to use.
The problem I have is I need these 30 or so themes in my solution so they remain under source control and manageable but they all get compiled into the XAP which is obviously not good as the app gets deployed somewhere and only requires 1 theme.
My question is really what do people think would be a suitable approach? Having a seperate solution for each theme so that it gets compiled into a seperate XAP and loaded dynamically seems like a lot of work. Is there a way to externally load these while they are part of the same solution?
Thanks for your time
Disclaimer: What I am recommending may not be the best for you. I only know a tiny bit about your project and know nothing about what you have told the customer (or boss) what you would deliver them.
If you are going to have x (where x is between 2 and 30-ish) themes. You will probably want to spend some time building a framework for supporting x themes. Since you won't want to change this framework every time you add a new theme, PRISM is perfect for you.
I would move everything out into x-ish silverlight class libraries. Obviously you could package similar themes together, like Seasons or Holidays, which would widdle down on the numbers of projects. Now don't forget that your Visual Studio Solution can have more than one project in it (Simply right click on the project and select Add->New Project).
Using PRISM is rather simple and there are a lot of resources to help you dynamically load xap files. It sounds like you may eventually want to rid yourself of problems associated with compiling in a bunch of similar logic.
Is there a way to externally load these while they are part of the same solution?
The answer is yes! You will have to compile your individual silverlight applications into XAP files and load them with PRISM.
It may seem like a lot of work, but when you've created the first few of them, it becomes second nature and really simple to add more XAP's to your list.
http://development-guides.silverbaylabs.org/Video/Silverlight-Prism
http://msdn.microsoft.com/en-us/magazine/dd943055.aspx
http://www.sparklingclient.com/prism-silverlight/