I am doing a project in WPF. I got a requirement to authenticate a user and providing accessibilty for the modules based on the role. Do i have a better way to achieve this in WPF.
It will depend in part on how secure you need the code to be.
For all your use cases, though, use a Model-View-ViewModel pattern. In each ViewModel, perhaps best placed in a base class for all your ViewModel classes, include a state variable which returns a string and raises the PropertyChanged event whenever the security state changes.
Base your presentation for each View class on the value of that string, following a pattern similar to the accepted answer to this SO question:
https://stackoverflow.com/questions/3868164/
The answer describes how to do this with boolean values, but you can use any string value other than "True" or "False" if your ViewModel state variable needs more than two states.
All .NET code, including WPF, can be easily reverse-engineered. If your code needs to be more secure than that, that is, if your use case assumes that your users will hack your WPF program, then you will want to obfuscate and/or encrypt much of the ViewModel code, using commercially available products like InishTech's SLPS or Dotfuscator or whatever.
Alternatively, you could use the same MVVM pattern and write a Silverlight application, but I'm not sure if a Silverlight user has access to the binary files the way a desktop WPF user would.
Related
I'm currently facing one of the most discussed problems in MVVM: I have a complex Model in my WPF application and I'm not sure how I should display its data to the View.
According to many answers here on StackOverflow and also to this article there are two ways:
to wrap the Model inside the ViewModel by adding a property in the ViewModel for each property in the Model
to expose the Model directly to the view without replicating the properties.
What I understood so far is that the first approach is better from a theoretical point of view, while the second one is a quick shortcut that should be avoided.
In the same article I previously linked, the author writes the following:
In reviewing the sample application from the Caliburn framework, they implement the VM using option 2.
I took a look at the Caliburn.Micro documentation and unfortunately it just uses a simple ViewModel without a real Model, so I don't know how to verify this statement.
Is the author right? Since I'm using Caliburn.Micro should I use the second approach instead of the first one in order to be more "compliant" with the framework implementation?
Since I'm using Caliburn.Micro should I use the second approach instead of the first one in order to be more "compliant" with the framework implementation?
No. Caliburn.Micro is just an MVVM library. How you implement the actual MVVM pattern is entirely up to you.
I agree with #Marek Dzikiewicz that you should wrap the model in a view model class that may implement the INotifyPropertyChanged interface and provide any other UI specific functionality. This code doesn't belong to a business object. You could refer to my answer here for more information:
Reuse the same models in ASP.NET MVC and WPF MVVM
Obviously if the model class is indeed a UI specific class that is not used in any other application and doesn't contain any business logic that is used on the server side, you could modify this class and bind to it directly. But then it is kind of a (sub) view model after all.
Usually it is better to expose view models because that allows you to add additional properties to control the way the data is displayed (for example formatting or concatenating data). However, if you don't need that, there is nothing wrong in exposing the model classes directly.
I'm creating an application on which I want different users to use it. I want to insert a variable, only modifiable at development mode. I think maybe there should be a way of using the App.Settings of the WPF Application, but, after one hour googling, I don't have a clear idea yet.
So, I need:
A variable that makes the WPF Application run at administration or client scope
If I have that variable in a specific role, I want to disable some controls
Any idea on where to look for a solution for this?
Well you could add to the base class of your ViewModels a property which contains the value reflecting the mode. As next step you could bind the IsEnabled property of the controls, which shall have this behavior, on this property of their related ViewModel.
Since you don't want to provide different modes with different states a.s.o., this seems to be the best approach.
I have a Silverlight application that is loading Entities from a WCF Service via DataBinding.
So I have several views with many textboxes whose textboxes contents are binded to a Entity properties.
I want to use Silverlight validation and I don't want to use the exceptions way (I have some entities with a lot of properties... and I don't want to repeat it every time I use it in a form...).
So I'm triying to use the IDataErrorInfo way, but I'm not sure how should I do it.
I think I should declare a client-side model with equivalent classes to the Service EF Model but implementing the IDataErrorInfo. This solution means duplicate the model code and make any way to translate from service model to client model.
The other solution could be to change the EF Model itself but I don't know if this is correct for the MVVM (this is really near to the view, isn't it).
Maybe there is another magical solution I don't know.
Any suggestions??
The recommended interface is actually INotifyDataErrorInfo
Which gives you a little more control and supports multiple errors. It's also a little bit easier to use in scenarios when you manually want to control when validation happens.
Basically, with this, you could create a validate method on your "client side" objects which goes through their properties, validates each one, and builds up a list of errors. (HasErrors becomes true, you notify ErrorsChanged and then the code that binds to your object does GetErrors.
With this way, you could build a validation engine and have each EF object poll your database for validation rules.
There's also this: http://msdn.microsoft.com/en-us/magazine/ee335695.aspx
If you have the option of annotating your EF classes on the client side instead of simply using the generated ones, you may be able to find an easy solution here.
I know this is slightly off-topic since you're using WCF
but if you were to use RIA Services, then it generates objects from your EF, and you can simply add some attributes to them in the RIA (it comes with comments telling you which attributes to use)
and it's very very simple.
but that advice is relevant only if you were to use RIA.
I'm about to use a user control developed by a different team (in the same company) and for the app we're developing we're attempting to describe all the data binding in XAML.
Now if I use a third party user control should I expect them to supply a basic ViewModel with hooks for my code or should I expect to write code to bind the user control to a ViewModel of my choice?
Cheers
AWC
It depends on the scope of the UserControl. If it is particular to the application and is unlikely to be useful elsewhere then yes, a public ViewModel should probably be supplied.
However, a public ViewModel is likely to be less useful where the control is expected to be re-usable. The control may use a ViewModel internally, but this should be kept private. Then the host application uses the control in a similar way to any other WPF control, and creates it's own view model to tie the control to the application.
In essence, a ViewModel is usually particular to an application - it is tailored specifically to the needs of that application. Whereas general purpose controls expose properties and events that allow them to be used in any application.
Write the controller class yourself. A reusable control should not know which type of data it's working with, unless it's specifically written for it. But then it wouldn't be very reusable :)
The control is supplied as a self contained unit. If it has it's own viewmodel internally which has hooks exposed that is all great, but to you it doesn't matter because you cannot manipulate it directly.
If you really feel the need then you should write your own viewmodel for the supplied control, as this abstracts the UI (the supplied control) from the controller (your code). That is one of the purposes of the pattern - to separate concerns, so you can swap out any part with minimal effect on the remaining parts.
But having said that, not every control is going to need its own viewmodel, instead you would use the supplied control as part of a larger user control, and write a viewmodel for that larger control.
Short question:
Do any of MS's built in Data Objects support INotifyPropertyChanged?
Long explination:
So I'm going to be displaying alot of data with databound controls.
The data is going to be chaging somewhat frequently with user interaction.
The application is a basic windows form app.
Rather than wire up events for all the data to the display controls I'm hoping that I can use data objects that implement INotifyPropertyChanged, that way the controls don't need to know the how, when or why their data changed just that they need to update themselves.
Sanity check:
Am I even barking up the right tree here?
The point of INotifyPropertyChange is to report property changes. To that extent, it's supposed to be implemented by specific model classes, not by general-purpose data objects. A more general solution for such objects is provided in form of PropertyDescriptor.AddValueChanged - since PropertyDescriptors can represent "virtual" properties, such as DataRow fields, or WPF attached properties.
I have been working for a few months on a rather large windows forms app, and we are using DataBinding and INotifyPropertyChanged for everything. It works really well, and I have no real problems to report. We are using our own classes, because there really isn't a data layer in this application, so I don't know for sure about the MS data classes.
BindableCollection< T > implements INotifyPropertyChanged