|
27.01.2014, 10:25 | #1 |
Участник
|
When I was writing my last post I had a distinct feeling that I was trampling over some boundaries of good NAV design. After all, you should not do stuff like that, NAV isn’t meant to do things like that, or at least that was how I felt.
And then two things happened. First, I asked myself: what the heck, why not? What exactly is NAV meant to do, and why not things like that? If folks at Vedbæk didn’t provide an out-of-the-box solution for the problem, why should the problem stay unsolved? Second, my dear friend and a fellow MVP, Hrvoje of Hudo’s Vibe, identified the thing as the mediator pattern. So, the thing I’ve done to NAV, civilized world has been doing to their programming environments for a long time. And then I decided to take it all to a different level altogether, and expand the simple class which didn’t do much but raise events on itself when its method was called, into a full-scale framework. And here it is, the mediator pattern incarnated into a brand new Dispatcher class, adapted to NAV, and with features that make it truly flexible. I do not dare starting to think what are all the situations where you could put this thing to use in NAV. Read on. In a nutshell, the mediator pattern allows different objects to interact and exchange information, without them having to be aware of each other, or ever calling each other directly. To illustrate an NAV example, it would be as if you clicked Post on a sales invoice, and the action never invoked codeunit 80. Instead, the action invoked the Mediator object, telling it to post the sales invoice, and the Mediator object notified the object in NAV that was in charge of posting sales invoices, and that object then invoked codeunit 80. The whole pattern decouples the dependencies to the maximum and allows flexibility and versatility beyond anything we know of in NAV. So, this Dispatcher object, which in itself is a .NET assembly that you can use through .NET Interoperability, enables this pattern by allowing objects to call the mediator class and asking it to dispatch the information to other objects. This information may be anything, and the mediator class would dispatch it to those other objects that are interested in that specific information. So, here are the features in a nutshell:
I have a thousand ideas of what I want to do with this framework to make it even better, but some of those may make things more complicated for consumption within NAV. Right now, this is not NAV specific, you can use this in any .NET projects, but it was created with NAV in mind. I plan to add support for generics, to make the whole framework aware of the type of data being dispatched, and then notifying only those subscribers who are registered for handling that data type. This would reduce the amount of coding tremendously. In any case, you can download the latest version on the link below, and I’ll make sure to post every updated version as soon as I have it ready: Download VjekoCom.Dispatcher, Version 1.0.5140.4706. Please let me know what you think of this version, as compared to the last one. Read this post at its original location at http://vjeko.com/blog/net-tips-trick...rn-on-steroids, or visit the original blog at http://vjeko.com. 5e33c5f6cb90c441bd1f23d5b9eeca34</img> </img> Читать дальше
__________________
Расскажите о новых и интересных блогах по Microsoft Dynamics, напишите личное сообщение администратору. |
|