关注点与性能的分离？答案

【问题标题】：Separation of concerns versus performance?关注点与性能的分离？
【发布时间】：2009-10-13 06:02:37
【问题描述】：

我有一个ASP.NET MVC 站点，我正在尝试找出控制器和模型（存储库）以及 HTML 帮助器功能的分离。

目标是查询相册信息的数据库表，并按年份分组显示。

步骤如下：

查询数据库，返回数据库信息的数据表。
将 Datatable 转换为 AlbumCollection（列表）
将专辑按年份存储到 ALbumDictionary
在单独的 HTML 表格中呈现每年。

根据这个请求，我可以看到： 1,2,3 全部在模型中，控制器简单地将 View 绑定到 AlbumDictionary 模型或者模型中的 1,2 并绑定到 AlbumCollection 和 HTML ViewHelper 中的 3 或者模型中的1,2 3在控制器中并绑定到Albumdictionary

想法？

在第一个循环中进行每次转换都会有最好的性能，但我不确定这是最好的关注点分离。

特别是对于上述问题，一般反馈会很有趣：关注点分离何时会影响性能，反之亦然？

【问题讨论】：

你在用什么？ linq to sql、nhibernate、实体框架...？
其实并没有，我只是想弄清楚这个操作会有多复杂......

标签： asp.net-mvc separation-of-concerns

【解决方案1】：

我曾经使用过一些真正可怕的软件，我确信从面向对象的角度来看，这些软件在设计人员看来不错，甚至可能易于维护，我想指出，用户会站在一边几乎每次都有表现。

如果性能差异可以忽略不计，请遵循关注点分离，如果不是，则尽一切可能获得最佳性能。我们需要停止担心可能需要维护的额外几分钟（一旦代码投入生产，可能每年触摸一次），并且更多地担心所有用户每天都会遇到的缓慢问题。我们喜欢说开发时间非常昂贵，我们需要尽量减少它，但事实是，开发时间通常比我们要求用户每天浪费的时间要便宜得多。

【讨论】：

【解决方案2】：

我会尽量让模型远离与渲染有关的任何事情。

我看到按年份分组非常接近渲染。这就是为什么我不会把它放到模型中，也不会放到控制器中。一种常见的方法是拥有一个 Poco 和 DAL/BLL 的模型以及另一个称为 ViewModel 的模型（强类型视图使用的模型）。这是准备渲染对象的好地方。

在 ViewModel 中，我会使用 Linq 按年份对专辑进行分组。希望这会足够快。

【讨论】：

【解决方案3】：

只有在以下任一情况下，我才会在控制器中进行分桶：

分桶只发生一次，我可以用一两个 simple 语句做到这一点；
它不止一次出现，但我可以通过 AlbumDictionary.BucketByYear() 语句来做到这一点。

否则我会使用模型来做到这一点。

【讨论】：