I wrote a simple WPF Application as an example:
Model:
public class User
{
public String FirstName { get; set; }
public String LastName { get; set; }
}
ViewModel:
//ViewModelBase contains base code for INotifyPropertyChanged
public class UserViewModel : ViewModelBase
{
public UserViewModel(User user)
{
_user = user ?? new User();
}
private User _user;
public String FirstName
{
get { return _user.FirstName; }
set
{
if (_user.FirstName != value)
{
开发者_运维技巧 _user.FirstName = value;
RaisePropertyChanged("FirstName", "Full Name");
}
}
}
public String LastName
{
get { return _user.LastName; }
set
{
if (_user.LastName!= value)
{
_user.LastName= value;
RaisePropertyChanged("LastName", "Full Name");
}
}
}
public String FullName
{
get { return String.Format("{0}, {1}", LastName, FirstName); }
}
}
Can I reuse my code in an MVC3 app? I figure the INotifyPropertyChanged stuff won't work, but can't I still reuse the ViewModel somehow?
No, not really. ViewModels and Controllers are governed by completely different design patterns.
Where MVVM and MVC shine is that they help break out business logic from your codebehind. You quite possibly can share your support code (code that you call from your VMs and Controllers but that isn't touched by any platform-centric designs) and models (depending on how they are coded).
I'm currently working on an app that combines an MVC website and a WPF application, and I do share models between them, and as much code as I can squeeze from my VMs and Controllers. But there is too much different between the two to use your VMs as Controllers and vice versa.
Your 'firstname' and 'lastname' method would just move into the model, as they aren't too much more than slightly more fancy getters and setters.
You're FullName method I'd be tempted to put in the controller as it's dealing with formatting but it does kind of have a basic and testable logic behind it.
As you say, I'm not sure you could use the NotifyProperty gubbins, but the methods in general should port over happily.
精彩评论