|
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.
|
|
|
|
|
Is it by any means possible to bind a single listview to two seperate observable collections? So, for example the first column is from collection A and the second column from collection B.
If so, how?
|
|
|
|
|
No you can't. What happens if the collections change independently of each other with one collection havin rows added while the other has rows removed?
|
|
|
|
|
No you cannot.
Databinding allows only one data source at a time.
|
|
|
|
|
I have a application written in WPF, C#. There are some settings of different modules of the application which I wanted to store, so that when application is launched, I can restore those settings.
I am thinking of using XML file and writing the settings through XML reader. I am using 'Application.CommonAppDataPath' to store the settings.
Is there a better way to implement this feature in WPF application and that can support Windows 7?
Also, as modules gets added to the application, settings get added to the file. What is the best design to handle addition of settings in future?
Please let me know the correct forum, If I have posted the query in wrong forum.
|
|
|
|
|
No need to hand job anything. Its already built into .NET for you for free. In solution explorer, expand the Properties folder and double click on "Settings.settings". Set up your application settings in that designer.
In your code, you'll access them like:
Properties.Settings.Default.<property name> = blah;
to save, you'd do:
Properties.Settings.Default.Save();
they'll be auto-loaded when your app is loaded.
There are some annoying details to get everything working in the real world, but this will get you started .
|
|
|
|
|
Thanks for the response. However, I am looking for clean way of loading/saving the application preferences in a loosely coupled manner. I am using MVVM architecture for my application and there are some global settings and some local settings pertaining to a module.
|
|
|
|
|
LMAO. How is one line of code not clean? This is perfectly appropriate for MVVM. Your VM would simply initialize its properties from the Properties.Settings.Default.<propname>. If you are too lazy for that , I guess you could write some reflection based code in your ViewModelBase to auto initialize the properties from the user settings. Seems like over engineering IMO though.
|
|
|
|
|
If your storage is fairly temporary, then you might want to consider Isolated Storage as an option.
Using this, you can store settings in memory. Remember thought that these settings can be cleared when the user so wants.
See this[^] for a fairly simple example.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
