I've got a plugin that needs access to certain information in order to populate its GUI elements properly. However, this plugin should not know about all other plugins, so I want it to request this information from the application.
In situations like this, I always create an interface for data exchange, and then pass this interface to plugins so that they can request the data when it's needed. However, I recently started to use the MVVM light toolkit because it's got some great features like RelayCommand and Messenger. In this case, I can totally see using Messenger -- plugins don't need the interface, because they can simply use Messenger.Default.Send<MyDataRequestMessage>(...). As long as they register the Receive handler, it's all good... or is it?
Which method would you favor, and why?
In case of plugins, an aggregator like MVVM Light's messenger is quite alright; alternatively, you could look at MEF (now part of .Net 4), which also enables auto-discovery and other such nice features, and you could use interfaces with that. So the answer is it depends :) Personally I'd favor Messenger for its simplicity, unless it's for a very large enterprise-y project maybe.
As Alex said, MEF was created just for this purpose. If you need to manage plug-ins, you're probably going to end up duplicating a lot of work that MEF provides for you if you don't use it.
There's no reason you can't use both MEF and MVVM Light. Your idea of communicating from your plug-in to your app using MVVM light's messenger is intriguing, and I hope it works for you. However, keep in mind that any plug-in could register to receive these same messages and you could end up with one plug-in receiving another plug-in's messages. This might not be an issue for you, but if you don't control who writes these extensions you definitely have a security hole there.
Good luck!
Related
I am porting my first (complex) application from WinForms to WPF. I am still in the research stage. One of the main tasks is separation of concerns (UI from logic), hence I would like to use a MVVM framework. I would like to use one of the more complete frameworks (Caliburn micro / MVVM cross / Prism/ ...)
The problem is this program currently needs access to serial ports in the Model layer (eventually to be replaced by bluetooth in the future). As far as I am aware this serial port requirement rules out using anything that depends on PCL or anything similar.
Further complicating things, the View layer will initially need to contain the WPF ribbon (again to be eventually replaced), which I believe will cause minor headaches with some frameworks.
In the future it would be nice if the majority of the codebase was portable to other OS's (hence the interest in MVVM cross).
Which framework would be easiest to acheive my goals? Or am I completely off track and best off sticking to a plain WPF application that has a separate project for business logic that gets called from a UI project, and moving to MVVM when com ports and ribbons are no longer needed?
EDIT (Update):
I have more of an understanding of PCL and its limitations now thanks to this article(MSDN). So it looks like I can use Serial Ports with PCL type frameworks if I have an interface and service locater for it, and have a separate (platform specific) project for the implementation of the serial port.
I think you are not totally of track! You are on the right way =)... the thing is ... it depends =).
If you go with WPF or a XAML based language you should definitely take advantage of the MVVM pattern! Because it's about separation of concerns, testabillity and structuring your software.
Before you pick a framework I would strongly suggest to dive more into the pattern (or guidance) MVVM itself. As soon as you got a clear understanding the framework is just a choice of taste.
Getting back to your question.
SerialPort: In MVVM you would probaly have a IDeviceService which could have an implementation for serial port, one for bluetooth, one for RFID. Your app talks only to IDeviceService and the implementation is easily swap-able with dependency injection (clear separation of concerns).
Ribbons: Ribbons is just the view and with that the representation of your data which is backed up by a viewmodel. If you decide to go with another UI control this can be exchanged as well. It depends surely on the behavior if you need to code a new view model but controls are just the view and should not contain much logic.
If you decide to go cross OS you might consider looking at a framework which builds upon the PCL http://msdn.microsoft.com/en-us/library/gg597391(v=vs.110).aspx ...
https://github.com/MvvmCross/MvvmCross mvvmcross is well appriciated for cross platform .Net MVVM development lately...
But after all I would suggest to try to get used to the MVVM concepts with smaller projects and get familiar and after that it is just your choice of taste to go with any of the framework or might role your own =)...
HTH
Is it possible to use Spring.net on WP7? Would you recommend others DI/IoC-Containers for WP7 and why?
As far as I know, Spring's IoC won't run on WP7 since WP7 has limited runtime libraries. Spring depends on things that just don't exist in the WP7 world.
One that I use, and can recommend is MicroIoC. It's small, simple to integrate, lightweight, and works great on WP7.
Alternative IoC container implementations for WP7 include:
Ninject
SimpleContainer from Caliburn.Micro.
MicroIoC
Funq by Clarius Consulting
OpenNetCF.IoC
I have had good success with TinyIoC https://github.com/grumpydev/TinyIoC
Is really simple, just include a single C# file in your solution and you're good to go! It also features an Autoregister function which maps interfaces to their implementation (given you have only one implementation) and classes automatically.
Also using TinyMessenger for loosely coupled messages between your presentation layer and business logics (say if you're using MVVM or some other presentation pattern).
I've heard lots of good things about Ninject (https://github.com/ninject/ninject) on WP7 - but not used it myself
I'm looking for some good real-world examples of interaction between Windows Presentation Foundation and Workflow Foundation. Most of the WF tutorials I see demonstrate use within console applications. I'm more curious about applications that use a rich WPF interface and WF. Particularly if they allow user defined workflows (allow users to design and run their own workflows on the fly).
I'm not sure what exactly you're looking for, but here are some links to information about actual real world applications using Workflow in desktop (WPF) applications in one way or another:
Sample Real World WF4 Integration
Infinity Workflow (there's a lot of info in the linked Word file)
Aderant Enterprise Workflow (also presented at PDC Windows Workflow Foundation Futures session)
Let me take the example of trying to make two workflows communicate with each other.
First you need to write a host. This is an extremely loaded proposition, because for two WF hosts to talk to each other, you will then also need to know WCF, and all mushy concepts of threading.
Then your WF will need to communicate with other WFs via the hosts. This makes sense because a WF doesn't keep running in memory for 3 months, when it is waiting for another WF to send an event. The WF sits in the database, and the communication occurs through the hosts.
Okay, even for simpler scenarios, for local in-process communication, you have the CallExternalMethod activity, and HandleExternalEvent activities. Even in this case, you have to talk via the host, because the WF might have been passivated to the database. So in order to do so, you have to remember to do 3 things, decorate your interface with the ExternalDataExchangeAttribute, eventargs needs to derive from ExternalDataEventArgs, and event args is serializable.
If you mess up in any of the items in #3, you get a very non-intuitive "InvalidOperationException". Sure the message says, "Service does not implement an interface with the ExternalDataExchange attribute", but it isn't until you look at the inner exception, that you really know what happened - i.e. you forgot to make it serializable. doh! But I did mark it as serializable. Actually, everything needs to be serializable, even the sender.
Then you have to connect the WF activities, via the proper interface names and method names you are using to communicate.
Finally, for even in-process WF communication, you have to remember to add your service to the ExternalDataExchangeService, and not the WF runtime. Otherwise, it will look like nobody is subscribing to the event. Not to mention, that this is one of those bug, that doesn't really throw an error. i.e. hard to track down!
So, in short, for the simplistic scenario of trying to make two workflows communicate, you need to have a good handle on the following:
*Writing windows apps (for the host),
*Threading,
*WCF,
*OOP Concepts,
*All concepts of serialization,
*Plenty of hooking up and non-intuitive details of WF itself,
*Ninja debugging skills.
Source:http://blah.winsmarts.com/2008-2-I've_been_here_before.aspx
The question is pretty vague but here is a possible awnser in this blog post I wrote. Basically I am rehosting the workflow designer to let end users change workflows as needed and let them run them right there and then. Of course you question could mean pretty much anything, like how to call a workflow service from a WPF form.
This is a sort of self promotion since the link is mine, but have a look.
Here is a sample project I did, which combines WF and WPF to simulate a ATM machine. The code works on some issues like handling the bookmarks, how to keep the workflow alive, and how to manipulate the UI from the workflow.
https://wpfwf.codeplex.com/
Can you please provide me with some tips/guidelines when architecting, designing and implementing a .net framework application, with the requirements given below:
It will be an analytical tool which will retrieve data from files, sql databases and may be cubes. So data layer should be able to handle that. The middleware should be totally independent of the other layers so probably need an IoC container (which one would you recommend)
It will be deployed on the local intranet
The front layer might be WPF application or Silverlight in future (for now, I am concentrating on Silverlight but the point is that it will change)
It should be easy to customise and improve it in the future without changing much of the code as the framework will be deployed for many clients
I need a way to store the configuration information, which will be picked up by the application on application load events to set its feel and look.
I have two months to implement it and looking for as many tips as possible.
SoC for a start
break your application into several assemblies that use IoC (interfaces + implementations):
application model assembly - all other assemblies will reference this one because these classes will be used for inter-communication - they will mostly be just POCOs
presentation assembly - references app model and business services - this one is either WPF or Silverlight in any case use MVVM to make your testing life easier
business services assembly - references app model and data repositories assembly
data repositories - these define repositories that actually get data from the stores
Then I'd create three additional ones:
file data providers
database providers
cube providers
Data repositories would reference all three and use them to provide necessary data.
If configuration becomes very complex with a lot of functionality then you should put it in a separate assembly as well and reference it by business services assembly.
Which MVVM library to use
Since you mentioned time I suppose you'll have hard time catching your deadline. When using MVVM (which I suggested to use) I also suggest you don't use a full blown PRISM (a.k.a. Composite Application Guidance from P&P) but rather go with MVVM Light Toolkit. It will take you less time to get on the bandwagon.
Code generation
In places where appropriate I suggest you use T4 to its full potential. I use it to import stored procedure calls to avoid using magic strings when calling stored procedures (and using their parameters). Check my blog post about it as well.
DAL technology/library
Don't write your own data access code using things like SqlConnection/SqlConnection functionality. There're many data access layer libraries/technologies today that you can use and not reinvent the wheel. If you know nHibernate, then use that. If you know EF, then use that. If you know anything else, use that. Anything that will provide/generate as much code for you as possible that is already tested and debugged.
So it all boils down to:
DRY + YAGNI
a.k.a. Don't repeat yourself and You ain't gonna need it = don't over-engineer you code.
Agile developers are supposed to be lazy
They should develop just as much as it's needed and no more! TDD implicitly provides this process by the red => green => refactor steps.
I would recommend using MVVM and Test Driven Development. The MVVM will give you good separation between the front and middleware, and the TDD will help control the chaos that comes with any nontrivial app development.
Have a look at the Composite Application Guidance from Microsoft's Patterns and Practices group, it may not match what you are doing exactly but will give you some good ideas.
From an architectural standpoint, I highly recommend taking a look at the Microsoft Application Architecture Guide. Since you are already using the Microsoft technology stack, I would consider using Microsoft Unity for IoC. You indicated that your presentation layer might use WPF or Silverlight, so take a look at using Windows Communication Foundation, as you will be somewhat constrained in Silverlight when it comes to communication with your data layer.
Has .NET (C#) anything like Django's Signals engine?
Our business logic become really complicated over few years of adding new features.
I'm going to re-architecture it. Currently all features are very coupled that makes regression errors while changing something one one place - some other place may be broken.
I really like Django's apps idea where separate applications introduce new functionality and are absolutely separate. Communication between apps is implemented though signals.
I wounder if there is something in .NET that allows to divide project business to many separated "apps" (plug-ins, zones, modules, you name it) and make communication using some kind of "signals".
For example we have simple order flow.
We can add "coupon app" that if exists in the project adds abilities to use discount coupon.
We can add "cross sale" module that if exists adds abilities to offer cross-sale products
Email notification module that if exists adds abilities to send order email notifications.
But in the same time all this modules are "self-contained" means that communication between them is done using emitting signals (ORDER_PROCCESS_START, ORDER_SUCCESS, etcs) and other modules can subscribe to this signals and process them in required way.
This architecture is not related to web, all business logic is processed on the server side like without working with HTTP directly.
I wonder if it's good architecture from code maintaining and testing point of few, is it possible to do this in .NET? Any drawbacks that I don't realize now?
I am not to familiar with Django - but immediately two frameworks come to mind
1) Prism
2) MEF
Now, I know thatt Prism is really a UI Pattern - but the event agregator which they use in it may be useful in segmenting / messaging between loosely coupled projects
My hunch is though something like MEF may be closer to what you are wanting, where you can make plugins to extend the functionality of the application.