I am trying to create a TPayLoad-free CompositePresentationEvent, that its delegate is parameterless.
I want to have a global application event that takes no parameters such as UserLoggedInEvent, UserGotIdleEvent etc. etc.
How should this be done with the Prism 4.0 event aggregation system?
This post clarified some things for me.
Anyway I realize now the the Prism EA system is really clumzy tho.
Here are some extension methods that focus on reducing the verbosity of the EA.
For logging and handling roles and permissions around the application and sub modules it's best to use Interfaces instead of event aggregation system.
Related
Firstly, I've never used threads, but have found lots of examples on the internet about their use but nothing that obviously answers my question.
I have a class that loads and manipulates a file(s). It is fairly CPU intensive so I intend to put it in its own thread so that the GUI remains responsive. However, I would also like to use a progress bar to indicate the current status of the file operations.
The question is, what is the best way of approaching this, i.e. How do I get my file class to tell the app where it's up to? Do I have to add thread specific code to my class? Or is there an interface I can implement? Or, am I approaching this all wrong. Additionally (sorry, another stupid question) I assume I need an indicator in my file class to tell the thread when it's finished?
I'm using VS2010 and intend to build the app with WPF (if that's relevant)
Thanks for any advice,
Bob
Since you are intending to use WPF, use a Dispatcher:
Build More Responsive Apps With The Dispatcher
(Otherwise, for Winforms use a BackgroundWorker)
Has anyone found a smart way to use NServiceBus, without having to implements that useless IMessage marker interface for all messages?
Especially, when using DomainEvents, I would absolutely hate to couple my domains to a specific servce bus implementation.
I just noticed that Udi is adding an Unobtrusive Mode to NServiceBus 3.0. It appears
that will address the issue. There's even a sample writeup, but you would have to pull the latest off github at this point (Feb 2012). If you're willing to put up with some potential instability to get pure POCO messages, you might give it a try.
The IMessage interface is needed so that NServiceBus can automatically register those types in the serializer. When using domain events, it isn't recommended to publish them directly on the bus - instead, a domain event handler would translate them to service-level events (which inherit IMessage).
You might be able to create your own interfaces implementing the NSB marker interface and then ILMerge the NSB dependencies into your own DLL. This should allow you to only require references to your own Dll and no external references to NSB.
Its what NSB does for its own dependencies so you should be able to extend the idea, be sure to check out the pitfalls of this approach though - Udi blogged about it recently
http://www.udidahan.com/2010/08/01/cautiously-merging-il/
Six months later, still nothing about this issue (fix/improve) ??
Summary of possible solutions:
1) ILMerge or..
2) Custom Dispatcher for custom wrapped messages.
All this because of the IMessage marker interface.
Is it possible to use RoutedCommands such as ApplicationCommand.Copy, ApplicationCommand.Paste, etc in Silverlight 4 beta version ?
No, RoutedCommands are not supported in Silverlight although the primitive ICommand is. Silverlight 3 had ICommand but never used it anywhere. Silverlight 4 adds support to button controls to have an ICommand associated.
However, the full featured routed commands are not supported. They were not particularly useful in WPF anyway because they placed the burden of handling the command logic on the UI control that handled them. As it turns out, it is far more useful to have an ICommand exposed from the ViewModel.
Check out http://www.codeplex.com/compositewpf for the Prism project which includes some very useful classes such as DelegateCommand.
Having said that, commands like Cut/Copy/Paste are different from most commands because they are a generic command that usually applies directly to the control upon which it's executed. This is much different from a Save command for example which has a very specific meaning to the application behind the UI. For these clipboard related commands I'd say it's fine to break from the traditional separation patterns and write some UI-specific code in the code behind and use FocusManager.GetFocusedElement() to figure out which control you need to operate on.
This is a pretty fundamental question when using NHibernate in a web application, but I don't see any agreed best practice when searching the web. I've seen it done in lots of different places:
Created and disposed in the Repository method - This just seems silly to me, since when you get the object it's already detached.
At the beginning and end of the Controller Action - This seems better, but annoying to have to do it for each action.
At the Application level, in global.asax beginrequest and endrequest - This seems the best idea, but again, I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
Maybe there are other approaches?
Can IoC containers help in some way here?
Maybe you know of a good resource on the web regarding this?
And - what method do you use?
Thanks
Session per Request is probably the most used approach.
I've seen some examples creating in Init instead of beginrequest (sharp architecture for instance) - although I am not sure why.
In IIS 7 You can have access to the Session state in the Init event of Global.asax. That's why sharp arch uses beginrequest.
As for session management I agree with you - Global.asax is the best place for it. Event if you want to have a clean separation between layers and remove DAL settings from UI you can use HttpModule for it.
Also you can have a look at ayende's blog. It explains his way of session management
I have a simple business workflow with the following conditions
Users need to change the workflow itself using a desinger
The workflow is a long rinning workflow, so it will be serialized
Is there a way to automate the task of versioning different workflow assemblies?
The versioning of different workflow assemblies is not a trivial task and has a lot of complications. Here you can find a series of posts that deal exactly with this.
You can rehost the WF designer in your own application to let the end users change workflows. As you are hosting the designer you pretty much control what they can do. For example you can prevent them from removing or disabling activities and only allow them to add specific new activities in predefined area's of the workflow. The best approach is to save these workflows as XOML files and start them as such. This does mean you cannot add code to the workflow itself but you are free to define your workflow base class derived from SequentialWorkflowActivity (or the state equivalent) and use that as the workflow base class. This allows you to add code and properties. For example you can still add a CodeActivity but you need to link to code in the base class.
Workflow serialization, or dehydration as it is called, is used with running workflows to persist them to disk. This uses standard .NET binary serialization and can be a but tricky due to the long running nature of workflows. But no big deal once you know what to look for. See http://msmvps.com/blogs/theproblemsolver/archive/2008/09/10/versioning-long-running-workfows.aspx for the start of a series of blog posts.
Not sure if you need it but there is also the capability to change already executing workflows. This uses the WorkflowChanges object. See here http://wiki.windowsworkflowfoundation.eu/default.aspx/WF/RuntimeModificationOfWorkflows.html for more details.
Here is another article on workflow versioning:
http://www.adefwebserver.com/DotNetNukeHELP/Workflow/VacationRequest3.htm
Basically you can version workflows that use assemblies if:
Any assembly used with workflows
must be strong named.
If a assembly
uses an interface it also must be strong
named and placed in a separate
assembly.
An entry in the web.config
can instruct asp.net where to find
the proper assembly.