Develop Reference

Business Logic when Model (Parent) contains a collection of Polymorphic Models (Children)

In MVVM architectures, specifically the Model layer; when a Collection<BasicModelType> is used full of objects that inherit/implement BasicModelType; how does one go about handling any business logic on the "Models" in the collection without having to implement a portion of the business logic in the "Models" themselves? (Assumption "as" and "is" usage is not allowed as it is poor OOP practice).
---Further Explanation below if above is not totally clear.---
"Model" means a basic class with just properties.
ViewModel gets the Model via a XMLService.
XMLService is just a class that knows how to create Models from what is in the XML document. (This is just to tell how the models got created)
OutputService is a class that knows how to use the Models to create an Output from the software based on what is in the Models. It also has other logic outside of what it needs to do with just the Models.
The Model includes a Collection of other ChildrenModels. The ChildrenModels are polymorphic in that they come from a BaseModel. Having a BaseModel is desirable as it allows them to be stored and presented to the user as a contiguous collection. Example below, apologies, as it is the simplest example I could think of.
Truck : Vehicle
Name
HasTrailer
Car : Vehicle
Name
HasSpoiler
The Logic defined in the OutputService would need to do different things depending on if the ChildModel in a given Model's Collection is a Truck or a Car. The issue is that of course, the ChildCollection is of the base class type Vehicle. The only time the actual type is known is during instantiation of the ChildModel object (and it is known because the type in the XML is specific).
Is there a common pattern to handle how the OutputService would apply any of its functionality to the ChildModel collection. It by definition would need to know each models type.
It seems COMPLETELY wrong to have switch statements checking the type (with as or is).
Of course a solution would be to include the logic from the "OutputService" in the actual ChildModel; just exposing the function that executed that logic in the BaseClass or an Interface. Then any object/service/veiwmodel could just iterate through the list calling said functions getting the Model specific results. But doesn't this essentially split the Business Logic up? Hasn't the "concerns" been sprinkled everywhere?

If you read The MVVM Pattern.
View
The view is responsible for defining the structure, layout, and
appearance of what the user sees on the screen. Ideally, the view is
defined purely with XAML, with a limited code-behind that does not
contain business logic.
Model
The model in MVVM is an implementation of the application's domain
model that includes a data model along with business and validation
logic. Examples of model objects include repositories, business
objects, data transfer objects (DTOs), Plain Old CLR Objects (POCOs),
and generated entity and proxy objects.
View Model
The view model acts as an intermediary between the view and the model,
and is responsible for handling the view logic. Typically, the view
model interacts with the model by invoking methods in the model
classes. The view model then provides data from the model in a form
that the view can easily use. The view model retrieves data from the
model and then makes the data available to the view, and may reformat
the data in some way that makes it simpler for the view to handle. The
view model also provides implementations of commands that a user of
the application initiates in the view. For example, when a user clicks
a button in the UI, that action can trigger a command in the view
model. The view model may also be responsible for defining logical
state changes that affect some aspect of the display in the view, such
as an indication that some operation is pending.
So from this we can see that you should split the business logic up using the child classes. Abstract the logic of creating an output depending on the child. If you have doubts in your OOP design, think of which is more maintainable. See SOLID (object-oriented design).

C# MVVM Where Does the Service Layer Sit?

I am attempting to develop a little program which will communicate with a device on a serial port. The program will be responsible for formatting user entered data and reading and presenting values received by the device. I am pretty new to WPF and MVVM and have achieved a basic understanding of the whole databinding / XAML mess (I think).
Currently my understanding goes something like:
View: UI only stuff. Binds to ViewModel.
ViewModel: Takes a model or various properties of a model and presents them in a way that the View can understand. Also provides a way for the view to modify the model.
Model: The data the UI presents and modifies.
Now I am at a loss as to what provides Models to the ViewModel such that the application as a whole is aware of changes to Models.
The Model currently looks something like the following. My device takes calibration records and can read back all the calibration records.
public class Device : ObservableObject
{
public ObservableCollection<CalibRecord> CalibRecords { get; set; }
private SerialPort sp;
public Device(SerialPort port)
{
this.sp = port;
this.CalibRecords = new ObservableCollection<CalibRecord>();
}
public void WriteCalibration(CalibRecord record)
{
/* Write a calibration record to the device */
}
public void ReadCalibration()
{
/* Read all calibration records from the device and update CalibRecords */
}
}
I am struggling for a place to put this guy so that it can be accessed by the entire application. Currently I instantiated it in the main window's ViewModel but then it can't be accessed by other ViewModels unless I inject it into the constructor. This is fine for a couple classes but gets unwieldy quickly the more classes a ViewModel needs.
Perhaps this is what the so-called "business logic" or "service layer" is. Can you help me understand where to put the business logic in an MVVM app? Or, do you guys have some examples I should look at that focuses on the whole application (particularly the business logic) and not just the MVVM stuff?

Your understanding of MVVM is correct, but the "textbook description" doesn't account for services. Typically this is done with dependency injection (DI). Define an interface, IMyDevice and implement it in a MyDevice class. Then register it with your DI container IMyDevice -> MyDevice. By using a DI container (properly) you'll also take yourself out of the VM construction picture. You would have a VM something like:
public class MyViewModel : ViewModelBase
{
public MyViewModel(IMyDevice myDevice)
{
}
}
to get an instance of the VM, you would do:
theDIContainer.Resolve<MyViewModel>();
and it would new up the MyViewModel class and automatically resolve and pass in the IMyDevice instance for you.
There is a lot more to DI then I covered here... just a basic 10,000 mile high answer to your question. Read up on DI and see how it comes into play with MVVM.

The mindset of MVVM is to separate in a loosely coupled manner layers, allowing each to be modified and tested without interfering with the other.
You test the ViewModel and mock the Models. You test the Models. Your Model may take form of several services automatically injected by some DI container. Subsequently there is as little as possible friction between the Models, the ViewModel. Eventually they may be deployed independently; this lowers maintenance and cost; that's the same mindset of that of microservices.
For instance, you might have a Model that is tested and can be used for a WPF app, mobile app, web app, etc. Your ViewModel however should not a priori be involved in another GUI. You can update your webapp without commit/deploy for the other and the Model; lower cost, lower duration commit-to-deploy (including testing).
When you start with cohesive classes and test them, it will be clear where to put what.
It's OK to have only a View and a ViewModel; though the Model should have the business logic if it's enough rich; you should have tests for the Model, tests for the ViewModel ( behavior of the UI). The VM and the Model layers can be much more complicated than just 2 classes, you may have multiple (automatic) dependency injections (check the excellent Dependency Injection in .NET, Mark Seemann).
Subsequently, logic (for your business) should go in the Model, not in the ViewModel; logic for the UI should go in the VM.
Regarding WPF, the View take the form of a UserControl with View.xaml (what you see) and View.xaml.cs (the code-behind); not all UI logic goes into the ViewModel; pure View logic goes into the code-behind. The code-behind contains in particular all the dependency properties, behavior logic (shared with the xaml code) etc.

Wrapping properties in WPF-compatible properties to implement INotifyPropertyChanged

In my WPF application, my Model class inherits from a class ParentClass as such:
Model : ParentClass, INotifyPropertyChanged
My application is simply meant to provide a UI to test and validate ParentClass. So Model really is not much more than an INotifyPropertyChanged implementation layed over ParentClass
However I still need to access the data from that parent class and have it be responsive to the UI.
Assuming Slicing is a property in ParentClass, and WPFSlicing is a property in Model, this is how I am currently doing it. I am wrapping every parent property in a WPF-compatible property.
public Thickness WPFSlicing
{
get { return Slicing; }
set
{
Slicing = value;
OnPropertyChanged("Slicing");
}
}
Is there a smarter way to do this? I have many properties in my parent class and this seems like a very uninspired method.

This is a very interesting question.
Typically, I've found that in MVVM applications, you're trying to isolate a model as an end-result -- a product/piece of data -- of the View Model. If you were to have a Bicycle shop, for example, you would see the Storefront as the View, the Sales Person as the ViewModel (assuming this is a customizable Bicycle that is built to order), and the Model as the finished Bicycle object.
In the case of building the Bicycle, while it is in a "prototyping" stage that needs to be represented, I tend to wrap that up in a ViewModel -- because there is logic in it. It seems like an extra step, but in the end, you can have validations at that ViewModel while constructing it. If your model is inflexible to have the INotifyPropertyChanged added to it (or if it was generated from a service), you'll have issues if you have "0" tires on the Bicycle -- that should cause problems!
A lot of folks tend to get a little lazier and see MVVM as a pattern that abstracts out prototyped models (where data input is going back/forth, updated) to models -- when they should in fact be ViewModels.
Per the example, I would have an MVVM Directory that looks like:
Models
-Bicycle (an object that can be passed across a service, etc -- data)
Views
-BicycleCreatorView (the view or data template of the model)
-StoreFrontView (the view of the entire store/app)
ViewModels
-BicycleCreatorViewModel (the view model which CONSTRUCTS a Bicycle model as the end result)
-StoreFrontViewModel (the view model for the entire store)
Now, you could very easily ALSO have the BicycleCreatorViewModel have a constructor which takes in a Bicycle model and pre-populates. That's not uncommon. Someone might come into a store and say, "Hey, can you make this similar to this other one? Here's what it looks like." While the end-result is to have another property (probably just a get {}) which actually renders a Bicycle object, IF validation is good and we don't have something unusual with 0 tires, no seat (maybe that's a feature?), etc.
So, in short -- I would always have your Model (if you cannot extend it in ANY way) be wrapped up into its OWN ViewModel, for this purpose. That would be the true MVVM pattern. You can always use stuff like ReactiveUI or other toolkits that can wrap the properties up. You may spend a little more time doing this, but the end-product will be far more flexible and less error-prone than one otherwise. Essentially you are doing this already, but you could probably rewrite it so it seems "cleaner" and has the line's drawn.
In theory, you might also inspect whether you could approach it in a method like this:
Is there an aspect-oriented toolkit you could use, potentially? Maybe make your classes partial to include INotifyPropertyChanged on the extension and then XmlIgnore certain pieces, if serialization is an issue/at question?
Problem is we have very little knowledge on where the model comes from and how you're using it. Hope that helps or gives you an interesting idea. Would love to see if you come up with a solution that is more "inspired" than the standard.

I offer an alternate view. This all can be extremly simply solved with AOP framework, such as PostSharp. All you do, is attach [NotifyPropertyChanged] attribute to your class, and your model has everything wired up.
http://www.postsharp.net/aspects/examples/inotifypropertychanged
Be warned though, it costs, but it can be good investment, imo.
Ps, it's matter of view, but I don't see anything wrong with having all the DOMAIN model classes implement INotifyPropertyChanged. It doesn't kill performance, the only downside is that it clutters the code a little. That's what I have done, my domain model entities implement from CommonEntity, and INotifyPropertyChanged. INotifyPropertyChanged is not part of WPF!
It works, and is definitely nicer than wrapping your models inside viewmodels.

What's the point of having models in WPF?

So far I have yet to see the value of having models in WPF. All my ViewModels, by convention, have an associated Model. Each of these Models is a virtual clone of the their respective ViewModel. Both the ViewModel and Model classes implement INotifyPropertyChanged and the ViewModel just delegates everything to the Model anyway.
Why bother having Models then? Why can't I just move my Model logic up into the ViewModel and call it a day?
It seems rather redundant (that is, not DRY) to have MVVM, and just use VVM by default unless some special edge case demands a Model.
If using explicit model classes better supports unit testing, for example, or some other best practice, I can see the value.

The model is just the low level application data.
The view model is more specific.
It's like a window tapping into the data tailored for the view.
It also augments the model with details needed for the view. A good example is pagination.
A model can have more than one view model. These view models would offer different aspects of the data.
You can create a mashup of different data sources. A view model cleanly façades the models involved.
That means there is no 1:1 relationship between models and view models.
So, if you just display the low level data without a lot of additional logic, features, summaries, aggregations, filters, etc. you can do away with view models and just use the model directly. This seems to be the case with your project.

The model can be auto-generated (Entity Framework), or it might not be a specific class at all (think of a DataTable).
I assume that if you say "I don't use a model", you do in fact use a model, you just don't call it that way.

First of all, even in MVVM you can expose your Model directly in the VM and bind through it to the Model. {Binding MyModel.MyModelsProperty} where DataContext = ViewModel that way you don't have to necessarily wrap everything unless that is just your style to do so.
The ViewModel and Model have different responsibilities. For example, consider designing a file explorer with a tree view of folders. Each node in the tree view is a Directory/Folder. The directories are the models and they have properties related to the file system. The ViewModel may wrap or expose these properties for the TreeView nodes to display (For example the Name of the directory), but it also adds additional information such as "IsEditing" and "IsExpanded" to determine the state that the node is in.

You're just talking about one pattern in MVVM, actually there are more.
In Stateful viewmodel you don't actually delegate things to Models, Viewmodel itself maintains its state, so as you said in this pattern you can almost ignore the model as you can have state in VM itself.
To create isolation between business logic and presentation, data
should be removed from the view. The stateful view model pattern moves
data into the view model using XAML data binding. This allows the view
model to be tested without constructing a view, and it allows the view
to change with minimal impact on the business logic.
In Stateless viewmodel you delegate the calls to Model, which is what you're probably referring to.
Note that you don't necessarily implement INotifyPropertyChanged in Model. Just implementing it in VM is fine as long as you don't change the properties directly in Model.
So why do we need VM and Model? VM is for supporting view like providing Commands, etc and Model is just to hold the piece of data abstract the same.

If you think of it as an abstraction, let's say you need to build a screen to display a list of Employees and make a Selection, Search or Filter. Then we break it up in components. You will require:
An Employee class (Model)
An EmployeeManagementViewModel to prepare and present your list of Employees and manage state changes for your View (e.g. can contain a SelectedEmployee, Filter Search text, etc) to be used by your EmployeeManagementView
A list of Employees (Which will live in your EmployeeManagementViewModel)
Most likely you will already have an Employee class. If that's the case then you just need to expose that model in your EmployeeManagementViewModel as an ObservableCollection of Employees.
In case you don't already have an Employee class you may decide to create an EmployeeViewModel and add your Employee properties there like FirstName, LastName, etc.
Technically this will work but conceptually it bothers me because an EmployeeViewModel is not an Employee (it contains an employee). If you're abstracting reality then, the blueprint of an Employee should not include properties or methods to be used by a View. To me Employee should be a POCO which could implement INotifyPropertyChanged and nothing more than that. You're separating View state from the Model itself. Having an Employee POCO makes it easier to UnitTest, create mock employees, map it to a database table through an ORM, etc.
As the name implies the ViewModel is the model for your View and the Model is the model for your business domain
Anyway that's how I see it. When I started doing MVVM work I had that same question but over the years seems like it makes sense.

In general, my Models end up being a Data Access Layer, be it through Entity Framework, a WCF proxy, or some other class.
Depending on concurrency issues, the class could be static or instanced. If you can separate the behavior enough, you could "split" the DAL classes into a separate model for each view model, but duplicate code could become a problem.

Wikipedia: MVVM
Model: as in the classic MVC pattern, the model refers to either (a) a domain model which represents the real state content (an object-oriented approach), or (b) the data access layer that represents that content (a data-centric approach).
Your ViewModel isn't a substitute for your domain Model. It acts as an intermidiate between your view and the model, including commands, binding collections to your view, validation, etc.
Your domain model should also be reusable across ViewModels. If you implement it all in the VM you will end up abusing the DRY principle by sharing specific VM logic across multiple VMs.

In my experience when you just use Domain models as the ViewModel (as a property of the VM) you end up with a lot of Keys that require you to either go get the text value and store somewhere else or you end up adding the property to the VM anyway. Your view typically has more info than just one single domain model (e.g. related objects, display values, text status values etc..), something that the Domain model has no need for and would ultimately weigh it down. The view model is dedicated to the needs of the view, it keeps coding the View simple and non-complex.

MVVM where to put Data Access Layer?

I am investigating WPF's MVVM design pattern. But am unsure where to put the Data Acess code?
In some examples I have looked at, data access is performed directly in the ViewModel. It seems odd to put something like linq to sql in the ViewModel? Other examples have a seperate project for Data Access, this seems more like it?
Is this there a general approach? I feel like I am missing something here!
Thanks

Here's how I've been organizing my MVVM w/ LINQ projects:
Model - I think of the Model as the state of the system. It provides an interface to the data, and it keeps track of system status. The Model does not know about the ViewModel or View--it just provides a public interface to its data and various events to let the consumers (usually ViewModels) know when the state has changed.
ViewModel - The ViewModel is in charge of organizing or structuring all the data needed by the View, keeping track of the status of the view (such as the currently selected row of a data grid), and responding to actions on the view (such as button pushes). It knows what the view needs, but it doesn't actually know about the view.
View - The View is the actual look and feel of the UI. It contains all the built-in and custom controls, how they arranged, and how they are styled. It knows about the ViewModel, but only for the purpose of binding to its properties.
Gateway - This is the part that directly addresses your question. The Gateway (which is basically my way of saying "DataAccessLayer") is its own separate layer. It contains all the code (including LINQ queries) to CRUD or select, insert, update, and delete data from/to your data source (database, XML file, etc.). It also provides a public interface to the Model, allowing the Model to focus on maintaining system state without having to concern itself with the details (i.e., the queries) needed to update the data source.
DataAccess Classes - In C#, these are very simple classes that model your elemental data objects. When you select something using a LINQ query, you will usually create an IEnumerable<T> or List<T> where T is one of your data objects. An example of a data object would be:
public class Person
{
public string Name { get; set; }
public int Age { get; set; }
}
The big advantage of a design like this is that it really separates your concerns. Everything has a specialized job, and it's (usually) pretty easy to know what kind of thing goes where.
The disadvantage is that it may be overkill for small projects. You end up creating a lot of infrastructure for public interfaces that basically pass a single wish through several layers. So, you might end up with a scenario like this: [user clicks Submit, ViewModel tells Model to AddNewPerson, Model tells Gateway to InsertPerson] instead of a scenario like this [user clicks Submit, ViewModel adds new record to the database directly].
Hope that helps.

I would add another layer, essentially what you want is a data factory. You want to create a set of classes that will CRUD to the database for you and return clean POCO objects to the ViewModel.
A good example to look at would the Nerd Dinner book. It covers MVC not MVVM but the patterns are very similar and the way they access data in that solution would be good starting point.
Hope this helps.

Data access should not be in the view model, as this is supposed to be a view specific (possibly simplified) representation of the domain model.
Use a mapper of some sort to map your view model (the VM in MVVM) to your model (the first M). New objects in your model can be created using the factory pattern. Once created, you can store them in a database using the repository pattern. The repositories would then represent your data access layer. In your repository you could use an O/R mapper like NHibernate or Entity Framework.
EDIT:
I see that GraemeF suggests putting the data access code in the model. This is a NOT a good approach, as this would force you to update your domain model if you were to move from e.g. SQL Server to Oracle or XML files. The domain objects should not have to worry about how they are persisted. The repository pattern isolates the domain from its persistence.

MVVM stands for Model, View, and ViewModel. The piece you are missing is the Model, which is where your data access code lives.
The ViewModel takes the Model and presents it to the View for display, so typically you would have something like this:
class PersonModel : IPerson
{
// data access stuff goes in here
public string Name { get; set; }
}
class PersonViewModel
{
IPerson _person;
public PersonViewModel(IPerson person)
{
_person = person;
}
public Name
{
get { return _person.Name; }
set { _person.Name = value; }
}
}
The PersonView would then bind to the properties of the PersonViewModel rather than directly to the model itself. In many cases you might already have a data access layer that knows nothing about MVVM (and nor should it) but you can still build ViewModels to present it to the view.

Your ViewModel should be a thin layer that just services the view. My rule of thumb: if it has to do with the presentation of the UI, then it belongs in the ViewModel, otherwise it should be in the Model.

The WPF Application Framework (WAF) contains a sample application that shows how the Model-View-ViewModel (MVVM) pattern might be used in combination with the Entity Framework.