Where is a good place for data calculation methods? What should it be called?

Question

I'm thinking of writing a class to store away some helpful methods that relate to my Model, sequences of my Model and my Repository. I don't think any of those are responsible for calculating anything. It's not really a service per se either.

I want to do something like this:

IEnumerable<Game> someGames;
...
int score = _something.CalculateScore(someGames);

What is this layer called? Could Helper be a good name?

Also, can the Model do some basic calculation like this:

class Ticket
{
    IList<Log> Log { get; }
    Tech LastUpdatedBy { get { return Log.Last().By; }
}

or is that out of scope for a model data class?

Answer 1

Layer separation is a logical thing, and should be treated with a degree of elasticity. The strict approach would be to remove any and all logic from the model layer, and have it store objects and retrieve them, and nothing else. According to this approach, all logic should reside in the business logic layer.

The other side of this coin is the relaxed approach, which doesn't really care if snippets of logic are scattered around, some in the model layer and others as far as the client-side code. This is more flexible, but should be used with more caution.

Personally, I'd leave the small snippets in the model layer. The data calculation methods are usually the heart of the business logic layer, and in some cases are statically placed in their own class, to be widely reused. This depends on your needs.

Answer 2

I would leave those methods in the Model. My rule of thumb is if it's generic enough that any implementation might be able to take advantage of it, it's OK to leave in the model, otherwise it belongs somewhere else.

Answer 3

Your use of the term "Model" suggests to me that you are using an MVC architecture. A common philosophy in MVC architectures is that Controllers should be as "skinny" as possible.

Using this approach, your CalculateScore() method should be part of your Model. Your Controller should contain only the logic necessary for selecting Views and interacting with requests from the user's browser.

The way I think of it is that if I converted my MVC web application to a console application I would keep the Model but throw away the Controllers and Views.