Place for Business Logic about template10

[mlafleur]

In most cases logic like that belongs in the ViewModel. If you think about the Model as a schema, your ViewModel would be a Stored Procedure for working with the data.

[lukaszciastko]

In case of applications that just read and write data, like, for example, a simple task manager, thinking about the Model as a schema is probably quite a good idea. After all, the app only needs to add new tasks to a table (e.g. in a database or a CSV file) and display them to the user. View Models can handle that. But what if an app needs to do some more advanced calculations? Let's say, we have an app that needs to calculate distance between two points (each point being a model class). In such a case, each point object can have a method called CalculateDistanceFromOtherPoint(Point point) or we could use a domain service (which would still be a part of the model). However, View Models wouldn't be a good place to put such logic, and if you discourage users from putting methods into model classes (which the template documentation does), this might actually lead to creating anemic Domain Models and overcowrded View Models that don't ahdere to Single Responsibility Principle and behave like a Swiss Army Knife.

[mlafleur]

Using your example of calculating distance, that strikes me as something that belongs out of band from the Model /and/ View Model. A better option would be to house that logic in a separate class entirely. The selection of MVVM or MVC does not remove the need for "utility functions" as it were.

What would make sense is adding a method to your Model that returns Model data in a format that the calculator can use. I've run into this exact scenario a few times and typically include an .AsPoint() or .AsLocation() method that returns the data in a format my calculation class can work with.

[JerryNixon]

This is a general question and not a Template 10 question. I will give you my personal response, but then I will close the issue. Next time you can ask these types of questions on StackOverflow and get lots of great feedback that way.

Anyway, the only two reasons to abstract logic out of a class into a separate class is either for reuse or for servicing. That is to say, you would take your logic out of your ViewModel if you cannot test it without abstracting it out, need it in more than one ViewModel, or because your ViewModel will never change but your logic is subject to frequently changing and you can service your project in some simpler way by having it removed. If, however, your logic is unique to that ViewModel and unlikely to change, it would be a long row to hoe to convince me you need yet another class. If it is because your class file is too large, then use a partial. Otherwise, I am a fan of putting logic where it is used and abstracting as little as possible for the ultimate sake of cost of maintenance. Some developers feel differently and create abstraction levels more frequently and they are not wrong in their own right. However, it's not what I prefer. Simple is almost always the best architectural pattern.