Organization of folders on VS Solution - winforms

Well, I'm a little worried about where to put the user controls and the forms (children and parents), the helpers classes and so on. So Im using RepositoryPattern for DataAccess and my Forms was added in the ViewLayer with any organization.
I want yours opinions about using some Architecture for deal with this, or just create some folders as the follow and take in consideration some app namespaces (example : CompanyName.View.Controls for UserControls components) :
ViewLayer :
|
|-> Controls
|-> Dependencies
|-> Diagram
|-> Forms
|-> Resources

The folder organization doesn't really matters - the major goal is easy-to-find-my-class. With a modern tools like ReSharper you usually have powerfull GoToClass helpers, so if you name your class properly, you can easilly find it.
Howerer, its more important to separate your code to assemblies properly - to handle class visibility in a right way with public/internal visibility scope.
My small project usual solution template:
Acme.MyProject.Components.csproj
DAO
Models
Controllers
Exceptions
Services
Utils
Acme.MyProject.Tests.csproj (depends on Components)
DAO
Models
Controllers
Services
Utils
Acme.MyProject.Site (aspnet web sie, depends on Components)
App_Code
Controls
Layout
When using WCF, I also create a small assembly .Entities, where I store all Data- and Operation contracts, to easilly reuse one in WCF clients

Related

how to achieve true loose coupling using Prism and Unity

I have developed a WPF application using Prism and Unity frameworks and I have some concerns regarding the following whether I have implemented them correctly or not.
Abstract classes / Interfaces - I have organized interfaces for all the layers in one assembly and then referenced it in the respective library for implementation. Now, the referenced library has access to all the non required interfaces of other layers. For e.g. the service layer has access to UI interfaces. Is this the proper implementation in terms of clear separation or should I split it into multiple assemblies.
View Model dependencies - I used EventAggregator mostly to communicate between view models. In some cases, I am passing the instance of other view models directly in the constructor and resolving it using DI container. I want to omit the direct view model dependency by introducing the interface to achieve clear separation. How can I organize the interface for view models into a separate assembly in such a way that the other developers could understand.To avoid creating multiple UI projects, I created only one single assembly and logically separated them into folders.
Abstract Module Class - Instead of specifying all the dependencies in bootstrapper.cs file, I factored them in respective module. Most of my class lib projects has references to Prism libraries. Thus, UI specific namespaces are added to non UI related projects. Is there any better approach to achieve this ?
Abstract classes / Interfaces
I'd go for exactly as many "interface-assemblies" as necessary, having too many of them hurts. Example: if you need to prevent layer 1 from potentially communicating with layer 3, put the layer 1-to-layer 2-interfaces in one assembly and those for layer 2-to-layer 3 in another one.
View Model dependencies
Normally, you shouldn't need to pass view models around at all. Pass around the data (a.k.a. model), the view models themselves don't hold any data that's either unavailable elsewhere or valuable to anyone but the view bound to the view model.
Abstract Module Class
Your prism application references prism... so what? As long as only the IModule implementations receive the IUnityContainer I wouldn't care at all. If someone needs to publish an event, he get's the IEventAggregator... That's an interface already, and you can inject a mock in your tests, so no need for further abstraction.

WPF "control injection"

I'm developing an application that both run as a standalone application and a plugin. We're using dependency injection to inject different implementations of the application logic.
The GUI in the standalone application and the plug-in is identical today, but we're seeing a need to do minor customizations to the GUI depending on the context. This is typically small changes, like providing different input mechanisms (e.g. a drop down list in the standalone version and a hierarchical selection control in the plug-in version). Typically the controls used in the plug-in version will be controls provided by the plug-in API.
Since there typically will be many small differences between the standalone GUI and plugin GUI rather than big components (e.g. buttons rather than pages in a tab panel) we do not wish to create one XAML for the plugin and one for the standalone sharing a common view-model.
Are there any patterns for injecting user controls in WPF?
Prism! :D it is a framework for MVVM/ dependency injection and WPF/Silverlight
See http://compositewpf.codeplex.com/ and Composing the User Interface

Silverlight Composite application

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.

Splitting app's parts in their own assemblies when using Prism

The MVVM approach encourages (or just gives the possibility to) splitting a WPF or Silverlight application into Model, ViewModel and View projects so all three could exist in their own assemblies.
Using Prism (and, in my case, MEF as a Dependency Injection Container), on the other hand, one can build a modular application that is divided into a set of functional units (named modules) and each unit, in this case, is a seperate assembly.
Am I right that in this case we can separate only a Model in an its own assembly, but View and ViewModel should sit in one assembly, representing one functional module?
First of all, module is not equal assembly. You can spread a module's parts between several assemblies (including Models, Views and ViewModels). Although, usually you place classes related to a module together in one DLL or XAP file (in case of Silverlight if your module is a separated Silverlight application).
As of your case, if a Model is a shared entity which can be used by several modules, Prism encourages to place it in so called Infrastructure assembly that keeps shared non-module specific logic. Otherwise, it could be a good idea to place MVVM parts together, since they solve common business tasks. In the future, if you need to replace implementation of one of the MVVM's parts, you can do it just adding a new one and adjusting container's mapping.
Yes, Prism encourages you to put everything (models, views and view models) into one self-contained functional module.
In any case, I would strongly NOT recommend you splitting views and view models into separate projects. This is because they are tightly coupled together and are developed side-by-side.
Well, there are two recommended approaches on how you organize you MVVM application. First is when you organize your project by layers and put you views and view models into separate folders inside a project. Second, when you create folders by feature and don't separate views and view models, i.e. they lie in the same folder side-by-side. I personally choose the second one because, as I mentioned, they are developed and maintained always together and this way it is very easy to find corresponding view or view model.

Prism: Looking for ideas of how to design apps that don't necessarily comply to a standard region layout

I have an app that has several modules that have completely different functionality and I'm trying to figure out the best way to implement this using prism.
To try and better explain, I'll try to use Northwind as an example. I have 3 modules, orders, customers & employees.
The customer module will allow you to do anything pertaining to a customer. Add, remove and edit. I'm going to use scope regions for the main view in the customer module to handle all the different views I need to show here.
In the scenario above, I only want to load a module when a user wants to work with say a customer, order or employee.
You have these modules laid out and realize that you need to be able to show Orders for customer or sales people which are obviously employees.
What would you do here in this scenario as you wouldn't want to create an entirely new modules for say employeeOrders and customerOrders and you wouldn't want to duplicate any order related code.
I'm starting to wonder if it's feasible to think about building a composite application using prism if you're building an app like Outlook, but for a LOB business app, I've yet to find a good sample of how to do this and not break some of the principles of MVVM and definitions of Prism in order to do so.
I'm just 3 weeks into Prism and still learning but this is the biggest issue I'm running into.
Any thoughts?
You should be using the Event Aggregator for these types of communication scenarios. Essentially, you want a module to provide functionality but also expose events that can be invoked from other modules. You can also register a service in the Unity container. For example:
public interface ICustomerOrderInvoker
{
void DisplayCustomerOrdersInRegion(string customerId, string regionName);
}
These techniques are somewhat orthogonal to MVVM. Your event handler can create a view/viewmodel pair and insert them into a region. Or your event handler can create a UserControl with all functionality implemented in code behind and adds it to a region. The beauty of the composite UI is that your modules can use MVVM and another team's modules can use straight forward user controls or MVP or MVC or anything really; the point is that all the modules are composed into one application regardless of how they are implemented because they use the patterns established in Prism like regions, events, etc.
In your particular case:
You have these modules laid out and realize that you need to be able to show Orders for customer or sales people which are obviously employees.
Your Order module will certainly be aware of the concept of a customer id since the Order entity is associated with a customer. The Order module should expose an CompositePresentationEvent that displays a view that has all the orders for a particular customer id.
The point of Prism is to create logically separate and loosely coupled pieces of functionality. This does not mean that the modules do not communicate with each other, but rather that the communication happens in a limited and loosely coupled manner. You can certainly write LOB applications using this pattern and MVVM; many of us have been for years now. :)
Im working on a similar problem (and am new to Prism too), as yet don't have a solution. I think when using Prism its tempting to use the framework as the reference implementation intends, but it doesn't need to be so.
Prism should (when used correctly) facilitate software development, not hinder it. So don't get too stuck in the idea that any implementation must meet strict decoupled refactorised super patternised standards!
What I am doing/intending to do is create a MainModule, which has in it much of my core functionality, including a MainView/MainViewModel user control. The Shell then has one region "Main" and on MainModule load the MainView is injected into it as per standard prism usage.
I'm using a Docking Manager from Telerik (compatible with Silverlight and WPF) on the MainView and have implemented a class IDockingManager / DockingManager class in Infrastructure which is registered with Unity as a singleton (ContainerControlledLifetimeManager) in the bootstrapper.
Anywhere in my app I can get the IDockingManager instance and inject a view by calling IDockingManager.DockView(IView view, DockingParameters args). The DockingParameters can contain information such as where to dock (Left, right, top, bottom, tabbed document) and also the parent container to dock in.
This is the part I've not got to yet - I can dock left/right/top/bottom on the main view but I want to implement an attached property or something on my child views registering them as a DockSite when docked. So for instance I could dock a Treeview on the left and dock underneath that a listview by using the Treeview name as parent DockSite and DockBottom as the side.
Hope that makes sense, I've rambled without really explaining too well. Basically what Im saying is Im not using regions at all (except to inject the MainView) in this application and have created a class to handle view injection into dockable containers. It's not strictly Prism but Prism is there to make my life easier, not the other way around ;)

Resources