|
How does my technique not allow for testing the VM? While running unit testing there would be no actual blocking model dialog box displayed. As I already told you, my approach is better precisely because no stub is required.
|
|
|
|
|
How do you know when unit testing is going on? I see absolutely nothing in the code that prevents the dialog box from being shown.
|
|
|
|
|
The view doesn't exist during unit testing.
|
|
|
|
|
Adrian Alexander wrote:
The view doesn't exist during unit testing.
Correct. So guess what happens during testing? *Nothing*. In your sample code, you set Message to your DialogPM object and the message box gets shown by the view that is bound to it. During testing, there is no view, so nothing happens. None of the code in the lamdas is tested.
Anyways, just a personal opinion, but the more I look at this, the more I don't like it. Seems like a lot more work then the service locator:
1) you have to add the MessageBoxHelper to your view xaml
2) you have to add a bindable / public DialogPM property to your VM
3) you can't use the lambdas inline because they are untestable as mentioned above and you would need to break them out into seperate methods and test them separately (not very cool if you only need a one or two line code block!)
I don't see how this is any easier or better then:
MessageBoxButtons result = ViewModelBase.GetService<IDialogService>().ShowMessageBox(...);
switch (result)
{
}
???
modified 30-Jan-12 12:57pm.
|
|
|
|
|
As you just pointed out, making the lamdas into methods would then mean you can directly call them for testing, so I don't see any problem there. In fact, those "lambdas" are ICommands like any other in the VM. In any case, the technique I suggest could easily be adjusted to work with a switch statement if you like doing it that way.
I prefer using binding (which everyone uses in the WPF apps anyway) and you're determined to use a service locator (which I don't see any need to introduce into my code). We've come a long way from your original claim that my approach is a "clear violation of MVVM". It is just a matter of personal taste as you said.
|
|
|
|
|
Adrian Alexander wrote: As you just pointed out, making the lamdas into methods would then mean you can
directly call them for testing, so I don't see any problem there.
Why would I want to break a single line of code into a separate method? So your "time saver" technique now requires a ton more work? Every single response I get from the message box, I would need to put into a separate method to test it? I suppose you could just have one method which takes the MessageBoxResult and have all your lambdas call it with the appropriate value. Seems silly though. 3 lambdas + 1 method.
Adrian Alexander wrote: In fact, those "lambdas" are ICommands like any other in the VM.
Yes, VMs expose ICommands, but not every bit of functionality in the VM is broken out into a separate ICommand. Thats absurd. ICommands are only created when you need to invoke some operation from the UI.
Using your technique, I would need to create 3 separate methods or 3 separate ICommands (if my message box happens to display Ok, Cancel & Retry for example). If I do go ahead and create ICommands, oh boy... now I need 3 separate ICommand fields and the code to new up those ICommands, etc. So much work!!! 
Now imagine if my VM displays messages boxes in 15 places and each message box has 2 or 3 buttons. Now I need 30 to 45 separate methods just to handle message box responses!!! OH MY LORD.
Adrian Alexander wrote: In any case, the technique I suggest could easily be adjusted to work with a
switch statement if you like doing it that way.
A better design then what you have now, but still lacking testability. You would again need to break out all the case statements into separate methods. ServiceLocator has no such requirement.
Adrian Alexander wrote: I prefer using binding (which everyone uses in the WPF apps anyway) and you're
determined to use a service locator (which I don't see any need to introduce
into my code).
You don't seem to have a clear understanding of the difference between the two.
Actually, I don't even use ServiceLocator in my new apps anymore. I use DI. If you took a survey on CP, you'll find almost everybody uses MEF and/or DI to pass around services.
Look, I'm not against coming up with new things... but you have yet to show how your VM remains testable without breaking out every message box case handling code into a separate method and without adding a lot of work for the developer.
ServiceLocator, DI and MEF have already solved all these problems.
|
|
|
|
|
SledgeHammer01 wrote: ICommands are only created when you need to invoke some operation from the UI.
That's exactly correct, and that's what's happening in this case. Just as you bind an ICommand to Button.Command, using my approach you associate an ICommand with a button on the message box.
I wish you the best of luck.
|
|
|
|
|
|
Using the code I have supplied, you would only need the additional methods. You would not need the additional ICommand members or properties.
And as I suggested earlier, you could easily modify the approach to accept just one callback method per message box. The method would accept the result value and you could use a switch statement if that's what you like.
|
|
|
|
|
Actually, you suggested creating ICommands for each before  .
Obviously, I think we can agree that the 45 method approach is bad .
Going the single callback / switch (result) route is starting to get better .
However, going back to my real world scenario of 15 message boxes in my VM, I'd need to create 15 methods. HandleMsgBox1(...), HandleMsgBox2(...), etc. because each MessageBox has its own handling code. You also complicate the handling code in certain scenarios because you may have to pass around a bunch of objects that you normally wouldn't have to.
I really suggest you read up on ServiceLocator here and why its so awesome:
Using a Service Locator to Work with MessageBoxes in an MVVM Application[^]
As you can see, you can do this WITHOUT the 15 extra functions and maintain testability . That was my point. Ok, I'll admit it to make you happy , your technique "fundamentally" works, I never said it did not... BUT it requires jumping through too many hoops to get it to work in the real world and maintain testability.
You can write your code any way you wish, but the "standard" MVVM practice is to use ServiceLocator, DI or MEF.
Personally, as I said, I use DI in new code which is ServiceLocator on steroids.
All the WPF "big boys"... say Pete O'Hanlon and Sacha Barber (who you can obviously respect a lot more then me ) are using MEF.
|
|
|
|
|
Indeed we do. Look for something from me and Sacha soon which uses and abuses MEF. 
|
|
|
|
|
The word "abuses" is, in my opinion, quite appropriate in regards to using MEF to display a message box.
|
|
|
|
|
Can you point me to some articles on these DI specifically.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
Honestly, when I was trying to figure out DI, I was never able to find any good articles, thats why it was so hard to wrap my head around. All the samples were very complicated . The way you write the code depends on what DI container you use (there are about 10+ open source ones -- I use my own light weight one).
Basically, using the ServiceLocator pattern, you'd write code like:
class MyClass : ViewModelBase
{
private IDialogService _dlgService = null;
public MyClass()
{
_dlgService = ViewModelBase.ServiceLocator.GetService<IDialogService>();
}
}
DI (Dependency Injection) does it automatically for you:
class MyClass : ViewModelBase
{
private IDialogService _dlgService = null;
public MyClass(IDialogService dlgService)
{
_dlgService = dlgService;
}
}
The benefit of DI is that depending on your MVVM framework, everything is automatic. In my MVVM framework, I have the DI integrated with the ViewLocatorService, so when the view is created, it uses the ViewLocator to automatically create the ViewModel. It automatically passes in all the dependent objects into your VM constructor.
Basically instead of new'ing up MyClass, you do something like:
MyClass m = ViewModelBase.DIContainer.Resolve<myclass>();
doesn't seem like much of a benefit when you are only taking in one service , but in a complex system, you could be taking in 10 services, and they could have dependencies of there own, etc.
Basically, DI handles passing in any registered objects into constructors and creating all necessary objects for you.
It also makes it easy to see what services a class is dependent on by looking at the constructor. A lot of the DI engines also allow you to not use the constructor method, but inject properties.
Like I said, I use my own light weight DI engine, but I think the most popular "main stream" ones are Unity and AutoFaq.
|
|
|
|
|
I'm sorry, but this is not the forum for airing grievances with votes. You have a perfectly adequate forum at the end of the posting for that.
|
|
|
|
|
I agree. I was pointing in that direction, but someone didn't follow.
|
|
|
|
|
error SocketError.AccessDenied on silverlight
|
|
|
|
|
Read this suggestion[^] then reformulate your question ONCE and someone may attempt to help.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
|
You need to open up a port (4502-4534) for socket communication in Silverlight.
This needs to be specified in the crossdomain or clientaccess policy file.
Read more here[^].
|
|
|
|
|
error SocketError.AccessDenied on silverlight
|
|
|
|
|
|
In a Silverlight app, assume you have UI, Data, Business, and WCF projects.
Does the UI talk to the service, which then talks to the BL, which then in turn talks to the DL?
Or does the UI talke to the BL, which then talkes to the service, which talks to the data??
Everything makes sense in someone's mind
|
|
|
|
|
In our structure we have 3 solutions:
Models holding the representation of the database objects.
WCF has the DAL and references the Models.
UI has the views and VMs and also references the Models and a service reference.
Within each solution there are additional projects depending on the solution required.
Most of the business logic is in the VM with some done in the WCF solution. As most of the business logic is driven by UI interaction we do it in the VM. However there are some cases where the UI makes a decision and there is a large processing requirement, this is done at the WCF or even in stored procedures. I actually prefer procs for this but am finding the WCF and C#/Linq manipulation is fairly simple.
You can't beat a stored proc for sheer grunt whan there is a lot of data to crunch.
Never underestimate the power of human stupidity
RAH
|
|
|
|
|
I would prefer the UI talking to the service, which in turn talks to the BL approach.
This article[^] ought to be of some interest to you.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
