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.