We Keep Coding

Should I implement business logic on a Model or a ViewModel

When I'm processing business logic in an MVVM app. Should I do this on the Model or the ViewModel?
For example, if I want to re-calculate costs after an Asset has been re-valued, should I operate on the Model?
Is there an advantage in doing this on the ViewModel instead?
What happens if I have a list of ViewModels, but I want to translate that into a list of Models so I can do some processing? I could expose the Model as a property of the ViewModel (and use that to build the list of Models). But that means that the View will be able to access properties of the original Model

My suggestion is to put logic in a service layer instead.
This is a middle layer between view model and model (which, in a real object oriented paradigm, should only contains properties).
So the correct life circle may be:
View model -> service -> model handling.
This allows also to reuse business logic code through others view model if needed

The Model's purpose is to represent (or model) your business domain. Therefore, business logic by definition goes in the Model, not the ViewModel.
The job of the ViewModel is to expose properties and fields of the Model, and prepare them for consumption by the View.
For instance, picture a banking application. The Model may represent an account. Perhaps the Model has an account balance. The job of the Model may be to track the balance and make sure certain invariants are maintained (such as not allowing a withdrawal that is larger than the balance). The job of the ViewModel may be to turn the balance into a string that is used as a binding in the View.
You want to keep as much logic out of the ViewModel as possible to keep your code reusable and loosely coupled.

Use the model if you are building a web app; and one level bellow the model i.e. the domain level if you are building a LAN/desk app.
Your problem - re-calculate costs after an asset has been re-valued - might not just be a user interface issue. A back-end application might want to do the same (for example, for automatically importing data). And then you have a choice of either duplicating business logic or rewiring to existing one.
Nothing wrong with using the same model for the back-end too. But models -especially disconnected ones- tend to be large data structures because they need to bring with them all data from reference tables (unless you want to do round trips to server and sacrifice your GUI experience). And that might affect performance if model is used.

if you model contain required data for calculation you can use model.if model does not contain the data means create view-model and get data to do the calculation.(With respect to Business logic )
if you want to pass this data to view create View Model It improves code re-use opportunities

mvvm confustion with the model and business layer connection

So I have been searching for a while and all my searches on the model portion are just confusing me.
I have been seeing many examples where the view model has a direct reference to the model and then sets the model's member variables. However isn't the model supposed to be a business object so that the business layer can do calculations with that data?
So...
1) Should I share the model between both UI and the Business layer so both are referencing the exact same objects (shouldn't each layer "hide" their contents from each other in which case this wouldnt be the best).
http://blog.trivadis.com/cfs-file.ashx/__key/communityserver-blogs-components-weblogfiles/00-00-00-01-50/1856.distributed_5F00_domain.png
2) Or should the model be in the business layer. Then the UI makes calls from the view model using provided business interfaces to access model info? This way the model itself is hidden from the UI. Similar to option 1's image except there would be some interface accessing the models and services.
3) Or UI does have the model. BUT I can see many occasions where the business layer would need this information resulting in multiple models which look relatively the exact same are made. Imagine that the entire picture below resides in the UI. Then there is a business layer below the model which the model accesses.
http://rarcher.azurewebsites.net/Images/mvvm00.png

The View never has direct access to the Model. The View is connected to the ViewModel via its DataContext.
The ViewModel has direct access to the Model and is able to recover values from the Model and set values into it as well as call methods so that actions occur. But the ViewModel does not have direct access to the View, there could 0, 1 or many View instances all looking at the same ViewModel and it would never know.
The Model does not know about the existence of the ViewModel or View. Therefore you could reuse the Model class in a different project without any dependency on WPF or even a user interface.
How you attach the Model to the ViewModel is up to you. You could pass a reference to the Model into the constructor of the ViewModel. Or provide a separate method or property that is called after the ViewModel is constructed.
For complete separation you would expose the same list of properties on the ViewModel as are present on the Model itself (or just the subset actually needed). The ViewModel can hook into the PropertyChanged event of the INotifyPropertyChanged interface that should be exposed from the Model. As it sees changes it can pass the change onto any watching View via its own properties and its own implementation of the INotifyPropertyChanged interface.

As #Phil Wright states in his answer, the Model should have no knowledge of the ViewModel or the View, so you are free to reuse your Models between different layers. In my experience, Models are generally simple POCOs with no dependencies on other layers.
Whether you reuse your Models between your layers is up to you. If you're using an ORM such as Entity Framework, your Models might be your entity classes. Your business layer might decide to use these entity classes, or you may want to abstract them or aggregate them or do something else with them. At the end of the day what goes in your Models is driven by what you want to store in them and how you want to use them, and SO can't really provide guidance on that because the question is so open-ended.
As far as WPF and MVVM are concerned, I like to think of the ViewModel as being an aggregator of sorts for one or more Models. You generally pass the Model(s) to the ViewModel somehow (through its constructor or whatever): the ViewModel then provides properties and commands that are used by the View (via binding) in order to read and/or change the state of the ViewModel. At some later point, the ViewModel may need to change the state of the Models that it was supplied with, to reflect the changes initiated by the View.
You may find that the Models needed by your business layer are slightly different to the Models used by your ViewModels, and unfortunately you can end-up writing a lot of very similar-looking Model code when this happens. In such cases, Model interfaces may help: there's nothing to say that the Models used by a ViewModel have to be concrete classes. So you could have a single "sort of complex" Model that has all the properties needed by both your ViewModels and your business layer, then expose that Model through two different interfaces (one for each layer) so that properties irrelevant to a particular layer are not visible to it (if that makes sense!).

is MVC model Poco class, structure having data or business layer?

I m new to MVC and will appreciate if you can clarify my question.
What is a model?
Is it just Poco class having fields/ properties, for example a Person class?
Or is a model a data structure having data in it, for example List<Person> or List<Users> ?
Or as per asp.net a working Model is a business layer or service layer, can have business rules, logic, validation and i can talk to other layers?
Thanks for your help and guiding me.

There are ViewModels and DataModels. Poco models are considered the DataModels.
Poco models can also be used as ViewModels but its better to use separate models for views. Because a ViewModel can consist of one or more Poco models.
Here you will find more details: http://rachelappel.com/use-viewmodels-to-manage-data-amp-organize-code-in-asp.net-mvc-applications

One important note "Model" in "ASP.Net MVC" is different than "Model" in classic MVC design pattern, so be careful when looking for definition/resources. "Model in classic MVC" covered in How should a model be structured in MVC?.
"Model" in ASP.Net MVC is object (usually class) that ideally provides all data needed to render particular view.
There is no restrictions on whether such object used for any other purpose. If you view shows one particular item from data access layer (like Person) you can easily share the same object in data access layer and use it as view model.
Note that as of MVC5 views can't call methods asynchronously, so it is good idea to make sure all data is present in the model class instance rather than letting view to call DB/other remote services.

Dal (with Entity Framework) and Model layers into MVC

First of all , I use EF into Dal layer (separeted project from MVC, same solution). The generated models from EF's EDMX file are the actual models from Model layer?? If so, how do I access these models to work in MVC's View layer? I think it's wrong accessing data layer directly from view to work with these models, and If I make a Model layer with "my models" and translate Dal's models into mine models... it'll be duplicated code.
Probably I'm getting something wrong, but most of egs. are with code first approach, and I can't figure out this.

You are right in your idea of not accessing access the Models in your DAL directly from your presentation layer.
To avoid duplicating code when translating your DAL objects into the Models used by your views, you could use something like AutoMapper, which is supposed to do the heavylifting for you in exactly that scenario.

I think it's wrong accessing data layer directly from view to work with these models...
That's right, the appropriate method is using View Model
When you have dozens of distinct values to pass to a view, the same flexibility that allows you to
quickly add a new entry, or rename an existing one, becomes your worst enemy .You are left on your
own to track item names and values; you get no help from Microsoft IntelliSense and compilers .
The only proven way to deal with complexity in software is through appropriate design. So defining an object model for each view helps you track what that view really needs. I suggest you define a
view-model class for each view you add to the application.
-- "Programming Microsoft ASP.NET MVC" by Dino Esposito
A ViewModel provides all information that your view requires to make itself. To transfer data from ViewModel and a business entity you can use AutoMapper.
Don't worry about duplication, those are two different concept and should be separated from each other; it makes your application easy to maintain.

I may be mistaking but to me, using generation from EDMX provides you with the DbContext which could be considered as the DAL and entities which could be considered as the Model.
So you might directly manipulate entity instances as your business object. Manipulation of the base through the DbContext should appear in the BLL layer. Additionally, you might implement DTOs where needed.
This, of course, assumes you want to use entity framework code generation. Other options like using POCOs might be more relevant considering your overall architecture.

I use a view model in my local project and the models in the other project. Then put references to the models im gonna use on the page in my view model. Then reference the view model on my page. Let me know if that sounds like something you want to do and I can edit in some code.

Using MVC3 With DBML

Right now I am using classes generated in the .dbml file and passing the data to the controller through an implementation of the repository pattern. My question is this, do I need to create classes that are essentially clones of the classes from the .dbml without the linq-to-sql and without certain flags, or the ID to have the proper separation of domain logic?

The clones you are referring to have a name: view models. And yes, you absolutely should be using view models. They are tailored to the specific requirements of a given view. The controller should then query the repository in order to fetch some domain models (autogenerated Linq-To-Sql class, EF entities, ...) and map them to a view model class which will be passed to the view. That's how IMHO every properly architected ASP.NET MVC application should be designed. You should not pass domain models to a view, nor receive any domain models as action parameters from a view. Only view models.
View models are not clones of a domain model. A view model could be mapped out from multiple domain models, or one domain model might break into multiple view models. This way the views have the full flexibility to represent the data independently of the way this data has been transported in the business layers.