关注点与性能的分离？
我有一个 ASP.NET MVC 站点，我正在尝试找出控制器的分离以及模型（存储库）和 HTML 帮助程序功能。
目标是查询相册信息的数据库表并按年份分组显示。
步骤为：
- 查询数据库并返回数据库信息的数据表。
- 将 Datatable 转换为 AlbumCollection（列表）
- 按年份将专辑存储到 ALbumDictionary
- 每年在单独的 HTML 表中渲染。
鉴于这个要求，我可以看到： 1,2,3都在模型中，控制器只是将View绑定到AlbumDictionary模型 或者 1,2 在模型中并绑定到 AlbumCollection，3 在 HTML ViewHelper 中 或者 1,2 在模型中 3 在控制器中并绑定到Albumdictionary
Thoughts？
在第一个循环中进行每次转换都会获得最佳性能，但我不确定这是最好的关注点分离。
特别是对于上述问题，一般反馈会很有趣：关注点分离何时会推翻性能，反之亦然？
I have an ASP.NET MVC site and I am trying to figure out separation of controller and model (repository) and HTML helper functionality.
The goal is to query a database table of photo albums information and display it grouped by year.
The steps are:
- Query database and return datatable of the database information.
- Convert Datatable to AlbumCollection (List)
- Bucket albums by year into ALbumDictionary
- Render each year in a seperate HTML table.
Given this request, I could see:
1,2,3 all in the model and the controller simply binds the View to the AlbumDictionary model
or
1,2 in the model and bind to the AlbumCollection and 3 in a HTML ViewHelper
or
1,2 in the model 3 in the controller and bind to the Albumdictionary
Thoughts?
Doing every conversion in the first loop would have the best performance but I am not sure it is the best separation of concerns.
In particular to the above question, generic feedback would be interesting: when does separation of concerns overrule performance or vise versa?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
作为一些真正可怕的软件的用户，我确信从面向对象的角度来看，这些软件对设计者来说看起来不错，甚至可能很容易维护，我想指出的是，用户几乎会在性能方面下降每次。
如果性能差异可以忽略不计，请遵循关注点分离，如果不是，请尽一切努力获得最佳性能。我们需要停止过多担心可能需要维护的额外几分钟（一旦进入产品，可能每年都会接触该代码一次）以及所有用户每天的缓慢问题。我们喜欢说开发时间是如此昂贵，以至于我们需要将其最小化，但事实是，开发时间通常比我们要求用户每天浪费的时间要便宜得多。
Having been a user of some truly horrendous software that I'm sure looked good from an object-oriented perspective to the designers and was even possibly easy to maintain, I want to point out that the users will come down on the side of performance almost every time.
If the performance difference is negligible, follow the separation of concerns, if it is not, do what it takes to get the best performance. We need to stop worrying as much about the extra few minutes to possibly maintain (maybe touching that code once a year once it's in prod) and more about slowness for all the users every day issue. We like to say that development time is so expensive that we need to minimize it, but the truth is that development time is often far cheaper than the amount of time we are asking our users to waste daily.
我会尽力使模型远离与渲染有关的任何内容。
我看到按年份分组非常接近渲染。这就是为什么我不会将其放入模型中，也不会放入控制器中。一种常见的方法是拥有一个 Poco 和 DAL/BLL 的模型以及另一个称为 ViewModel 的模型（强类型视图使用的模型）。这是准备渲染对象的好地方。
在 ViewModel 中，我会使用 Linq 按年份对专辑进行分组。希望这足够快。
I would try to keep the Model clear of anything that has to do with rendering.
I see the grouping by year pretty close to rendering. Thats why I would not put it into Model and also not into the Controller. A common aproach is to have a Model of Poco and DAL/BLL and anonther Model called ViewModel (the Model used by the strongly typed View). This is a good place to prepare the objects for rendering.
In ViewModel I would use Linq to group the albums by years. This will hopefully be fast enough.
仅当满足以下任一条件时，我才会在控制器中进行分桶：
分桶仅发生一次，我可以使用一个或两个简单语句来完成；
它发生不止一次，但我只需使用
AlbumDictionary.BucketByYear()语句即可做到这一点。否则我会使用模型来做到这一点。
I would do the bucketing in the controller only if either:
the bucketing occurs just once and I can do that with one or two simple statements;
It occurs more than once but I can do that with just a
AlbumDictionary.BucketByYear()statement.Otherwise I'd use models to do that.