My Application has the following structure:
myproject (primary Silverlight project)
myproject.Web (website for the app)
myproject.Controls (Class library so I could do some inheritance with controls)
myproject.Classes (Classes representing the data the controls bind to)
It seemed like a good idea having these split into projects with their own sub-namespaces, but I'm running into a lot of coupling issues and that is leading to circular dependency namespace problems.
From what little iOS development I have done, it feels kind of like I am trying to roll my own MVC solution here. What is the recommended way of going about having controls (essentially forms) backed by data in a Silverlight app?
The projects look fine provided the namespaces and assembly names match. You can do the following:
myproject.Classes Can reference none
myproject.Controls Can reference myproject.Classes
myproject Can reference myproject.Controls AND myproject.Classes
myproject.Web Can reference myproject.Classes, but shouldn't need to
I suggest doing that split within the primary Silverlight application itself (a single project with multiple folders). Unless you know right now that you will have to reuse the code within the classes and controls namespaces within different Silverlight applications, I would avoid it. Silverlight is UI, anything you will want to reuse should be in the ASP.NET part of the project (logic, db access, business rules, etc).
If you take this approach, your UI won't become an albatross around your neck.
Keep your Silverlight applications thin, fast and pretty - I promise you won't regret it.
EDIT: The downvote made me realize I was unclear (clearer, more concise version below):
Don't split your solutions into projects based on namespaces - it leads to needless complication. Use namespaces within projects to organize code. Keep project counts to a minimum, and only split when there is a compelling need.
Good Luck!
Related
Is it possible to share viewmodels across platforms - WPF/Silverlight? I started down the path of putting my VMs in a separate assembly and soon came to ICommand - which then led me to ask this question? Is this possible, and if so is it good to do so? We have a possibility in the future of having a client application for WPF and Silverlight, so I would like to not have to duplicate VMs for both.
You can potentially do this using the Portable Library Tools CTP. This allows you to target the full framework as well as Silverlight in a single library project.
Otherwise, it is possible, sort of. You still need two separate projects (for practical purposes), but can typically use a single source file. Have each project using the same source files keeps the reuse in place - but does require manual synchronization of the files. You can also add platform-specific functionality easily in this case via partial classes or defines, which does help to keep some of the workarounds for missing Silverlight functionality easy to maintain.
[Almost] whatever is possible in Silverlight, is possible in WPF, too. So if you have a VM working in Silverlight, it will [mostly] work with WPF.
From the other point of view, WPF offers richer possibilities, so you might want to use them in your WPF part of code. You can use the usual #ifdef Silverlight-like tricks.
Also, this question might be useful.
I downloaded Prism v4 and ran the installer. I went into the directory and ran the two following batch files:
Desktop only - Open Modularity With Mef QuickStart.bat
Desktop only - Open Modularity With Unity QuickStart.bat
When I compile these applications, I don't see any real difference. I've searched for MEF vs Unity and I've found some pros/cons, but nothing that specifically states whether one is "better" (and I know that is subjective) with use in Prism. I guess perhaps if I list my requirements someone can point me to the correct technologies to use (even if it's not Prism 4).
The application is to be written in WPF (NOT Silverlight).
The main application will be extremely thin.
The main application will use a Web Service to build the menu of the "apps/modules" a person has access to.
The "apps/modules" will be completely contained in other managed libraries.
The main application gets views and viewmodels by reflecting into these DLLs.
The main application should feed in services for logging, etc. into these "apps/modules".
For example:
A basic user might have the options of:
ViewOnly Address record
All items Address related are within Address.dll.
An advanced user might have the options of:
New Address record
Open Address record (update/delete)
Manage users
All items Address related are within Address.dll.
All items Manage related are within Admin.dll.
The app should not actually reference either of these DLLs, I plan to reflect into them so that if there are 100 different modules and a user only has access to 2 of them, only 2 of them are downloaded and used. Whereas a user that has access to 10 of them gets those 10.
I've already solved the downloading DLL via WebService. :)
None is "better": they are different things.
IMO your choice should be driven only by your requirements. Based on the requirements you posted here I would suggest you to use MEF, because you have modules contained in DLLs and the main app is unaware of modules to load. Those tasks are the reason that why MEF exists.
Anyway you could use them both: MEF for modularity and Unity to take advantages of dependency injection (testability, reusability, ...)
If all the modules are not recompiled at the same time as the app, then MEF gives you lots of ways to cope with changing interfaces in the main app. Otherwise MEF may be more complex then you need.
I've been using Unity over a year with PRISM but I've noticed some serious memory leaking issues. Hence I decided to give PRISM 4 and MEF a go. What I've done is firstly converting my app to use PRISM 4 with Unity. Then I converted a branch to use MEF.
It may sound funny but MEF seems to handle memory consumption and release somehow better than Unity.
Would be nice to hear whether others have made the same experience?
Regard to your question whether MEF and UNITY can work nicely with each other, i can tell you that they are working really well with each other. I have developed a proof of concept application which used PRISM, Unity and MEF.
I have a a WPF prism desktop app with a few modules. In the past I've put all my localized resources in common resource files in the infrastructure assembly and referenced it in all modules.
But lately I have been wondering if that is indeed the right approach from a maintainence perspective. In essence it also sort of breaks modularity. Would having module specific resource files in the the modules themselves be a better approach in the long run?
All thoughts appreciated.
As far as one of Prism's main targets is modularity it just seems obvious to put your resources only in the appropriate assembly. Sharing resources via one centralized assembly is the opposite of modularity.
Doing it the centralized way will get you another type of DLL hell at the time you want to add more (optional) modules. You will have to update the common assembly without the knowledge of the modules that use the assembly. And determining which module is present just again violates the modularity itself. The other way is to always update the common assembly to the latest version.
Whatever you do, following the centralized approach forces you to build all your modules backward-compatible.
This is my point of view at the moment. But as far as I'm working with Prism for only a few weeks now I'm not quite sure if my statement is the way how it should be done.
I never have references between the individual modules when using Prism (unless one module is indeed an enhancement of another). I tend to put shared resources, interfaces etc. in a 'common'-assembly that is referenced by all modules and the assembly containing the shell. Things that implement an interface is then retrieved via the IoC-container and the implementation is placed in the module where it 'belongs'.
As you write - having them in the infrastructure module breaks one of the ideas behind Prism.
I have a WPF application (KaleidoscopeApplication) organized as follows:
Solution (6 projects)
Cryptography (DLL)
Rfid (DLL)
KaleidoscopeApplication (buildable "startup project")
Basically, KaleidoscopeApplication contains a bunch of resources (sounds, images, etc) and your standard WPF junk (App.xaml, App.xaml.cs, other xaml and code).
I need to create a new application that is very similar to Kaleidoscope, but I'm not sure of the best way to organize. This new app will need access to much of the same code and resources as Kaleidoscope. Preferably, I would like to create a new project in the solution, then simply use the "set as startup project" to pick which app I want to build. However, will I be able to access (share) the Resources folder of Kaleidoscope?
I know I will be able to access much of the code if I simply add a reference to the project and include a "using Kaleidoscope". But the resources I'm not so sure about.
Is this the right way to organize or am I asking for trouble in the future?
Thanks in advance!
The recommended solution in this case would be to refactor the resources and any common required code into a separate Assembly that both UI applications could use. You will probably need to do some manual tweaking to make sure everything is exposed the way you need it to be, but it'll make things cleaner in the long run.
I agree with Dan about this. You definitely need a common type of project to put all those shared classes and resources, and one for your start up. From there, you can easily add new projects by following the same kind of pattern of separation of concerns.
I'm developing a project using the MVVM pattern in WPF.
One of the key benefits to MVVM is maintaining clear separation between business logic and presentation.
As a test to see how well separated everything actually was, over the weekend I spiked moving all ViewModels, Models, and business logic to a separate .dll. The .exe was left as a thin presentation layer.
This worked, seamlessly, first try.
I've already seen benefits to keeping views (xaml, presentation) in the .exe and core logic in its own dll. For example, there's no longer any dilemma in my mind about whether code-behind in Xaml is an issue: I'm comfortable with it if it becomes necessary, since I know it's presentation specific.
So far this exe/dll separation has worked so well that my question is: Has anyone experienced any downside to this approach?
Related question: Implementing MVVM in WPF without using System.Windows.Input.ICommand
We use this kind of separation in all of our products because it helps us to see if any code violates against the UI - business logic separation.
Most times we do it the same way as you have suggested:
Sample.Presentation.exe (Contains all the WPF stuff, thin assembly)
Sample.Applications.dll (Is responsible to the application's workflow, here are all ViewModels)
Sample.Domain.dll (Here are the business rules)
We don't have encountered any issues yet and I don't expect to see any problems in future.
I don't see any spcific issues with this approach besides the general pro/con for using few/many projects.
2 weeks now with my Model & View Models in a dll, my xaml in an exe and no problems whatsoever.
The actual question is ... what are assembles for?
They are a way to separate logic making it unavailable to other code unless you add a reference, so in fact they are a way of hiding parts of code from other parts.
Given this purpose and the way you are using it I would say that you're doing it right.
Having said that I find much easier to verify that the Views do not have any code behind in code reviews and keep the views in the same assembly. Less projects = faster compile and load times.