Question

我正在考虑编写一个类来存储一些与我的模型，模型序列和我的存储库相关的有用方法。我不认为其中任何人负责计算任何东西。它本身并不是真正的服务。

我想做这样的事情：

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

这层叫什么？ Helper可以成为一个好名字吗？

此外，模型可以做这样的基本计算：

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

或者是否超出了模型数据类的范围？

Answer 1

您对“模型”一词的使用向我表明您使用的是MVC架构。 MVC架构中的一个共同理念是Controllers should be as "skinny" as possible。

使用此方法，您的CalculateScore（）方法应该是模型的一部分。您的控制器应仅包含选择视图和与用户浏览器请求交互所需的逻辑。

我想到的方法是，如果我将我的MVC Web应用程序转换为控制台应用程序，我会保留模型，但丢掉控制器和视图。

Answer 2

层分离是一个合乎逻辑的事情，应该有一定程度的弹性处理。严格的方法是从模型层中删除任何和所有逻辑，并让它存储对象并检索它们，而不是其他任何东西。根据这种方法，所有逻辑都应该驻留在业务逻辑层中。

这个硬币的另一面是放松的方法，它并不关心逻辑片段是否散布在周围，一些在模型层中，另一些在客户端代码中。这更灵活，但应谨慎使用。

就个人而言，我会将小片段留在模型层中。数据计算方法通常是业务逻辑层的核心，并且在某些情况下静态地放置在它们自己的类中，以便被广泛地重用。这取决于您的需求。

Answer 3

我会将这些方法留在模型中。我的经验法则是，如果它足够通用，任何实现都可以利用它，可以留在模型中，否则它属于其他地方。