改善ASP.NETMVC代码库的5点建议
刚刚检查完支持工单中的一些代码,笔者想针对 ASP.NET MVC 应用的改进写一些建议。这些内容仍在笔者脑海中,愿与各位一同分享。若你已使用 MVC 一段时间,那么以下内容可能并不新鲜。本文更适用于不常使用 MVC 或尚未充分了解 MVC 的读者。
成都创新互联专业为企业提供象山网站建设、象山做网站、象山网站设计、象山网站制作等企业网站建设、网页设计与制作、象山企业网站模板建站服务,10余年象山做网站经验,不只是建网站,更提供有价值的思路和整体网络服务。
假设以下场景:你想弄清楚一个网络应用在生产环境下为何消耗了 Web 服务器2GB 内存,于是,你将生产环境中运行的应用版本部署到本地运行,用于分析和调试。
仔细查看代码后,你认真地分析,可能还时不时摇摇头,最终弄清了问题的本质,那么此时,你应该给出反馈了。
这就是笔者今天的经历,从中总结出5点建议,希望能使读者在使用 ASP.NET MVC 代码时更加得心应手。
1、了解问题范畴内的查询
笔者收到的支持工单,其根本原因在于,从数据库中提取了大量数据,导致占用了过量内存。
这一问题十分常见。假如你建立了一个普通的博客,其中包含了文章以及多种媒体(图片、视频、附件)。你将一个 Media 数组放到 Post 域对象中,后者将所有图片数据储存在一个字节数组中。由于你使用了 ORM,因此需要采用某种方法将域模型设计完善;我们都经历过这一步。
public class BlogPost { public ICollectionMedia { get; set; } } public class BlogMedia { public byte[] Data { get; set; } public string Name { get; set; } }
这种设计并没有大的不妥,你很准确地建立了域模型。但问题在于,当你通过最常用的 ORM 发起查询时,所有与博客文章相关的数据都会被加载出来。
public IListGetNewestPosts(int take) { return _db.BlogPosts.OrderByDescending(p => p.PostDate).Take(take).ToList(); }
这一行看起来毫无问题(除非你曾受其困扰,所以了解它并非无害),但如果不取消延迟加载或没让 ORM 忽略日志媒体上的大「Data」属性,那么就可能导致非常严重的后果。
你应当了解 ORM 是如何进行查询和映射对象的,并确保所查询内容就是需要的内容(比如使用 projection),这一点十分重要。
public IListGetNewestPosts(int take) { return _db.BlogPosts.OrderByDescending(p => p.PostDate).Take(take).Select(p => new PostSummary() { Title = p.Title, Id = p.Id }).ToList(); }
这能确保只抓取任务真正需要的数据量。如果你要做的仅仅是使用标题和 ID 在主页上建立一个链接,那么得到这俩属性就够了。
你可以在知识库中准备5种以上的方法,为使用户界面更加完善,再仔细也不为过。
2、不要从视图中调用知识库
这一条比较难注意到。设想 MVC 视图中的以下代码:
@foreach(var post in Model.RelatedPosts) { ... }
看起来没什么问题,但如果仔细看看这一模型属性中隐含的内容呢?
public class MyViewModel { public IListRelatedPosts { get { return new BlogRepository().GetRelatedPosts(this.Tags); } } }
呀!「视图模型」中含有业务逻辑,此外还直接调用了一个数据存取方法。如此一来,数据存取代码被引入了陌生的区域,并隐藏在属性中。将此代码移动到控制器中,便于对其进行讨论并有意识地为视图模型添加内容。
此处正好说明一下,适当的单元测试可帮助发现此类问题;由于肯定不能拦截对这此类方法的调用,你可能会恍然大悟,不该将知识库注入视图模型中。
3、充分利用局部模块和子动作
如需在视图中执行业务逻辑,那就应重新考虑视图模型和逻辑。不建议在 MVC Razor 视图中执行此类操作。
@{ var blogController = new BlogController(); }
-
@foreach(var tag in blogController.GetTagsForPost(p.Id)) {
- @tag.Name }
切勿在视图中使用业务逻辑,但除此之外,你可以创建一个控制器!将业务逻辑移动到动作方法中,并将视图模型用于原本的用途。还可以将业务逻辑移动到单独的动作方法中,这一动作方法仅在视图内被调用,这样就可在必要时单独对其进行缓存。
//In the controller: [ChildActionOnly] [OutputCache(Duration=2000)] public ActionResult TagsForPost(int postId) { return View(); } //In the view: @{Html.RenderAction("TagsForPost", new { postId = p.Id });}
注意 「ChildActionOnly」 属性。MSDN中提到:
任何一个标有 「ChildActionOnlyAttribute」的方法都只能与 「Action」或「RenderAction」HTML 扩展方法一同被调用。
这就意味着,没有人能通过操作 URL 来访问你的子动作(如果你采用了默认路径)。
在 MVC 库中,局部模块和子动作都是很有用的工具,所以充分利用起来吧!
4、缓存重要的东西
有了以上的代码做铺垫,如果只缓存视图模型,又会有怎样的效果呢?
public ActionResult Index() { var homepageViewModel = HttpContext.Current.Cache["homepageModel"] as HomepageViewModel; if (homepageViewModel == null) { homepageViewModel = new HomepageViewModel(); homepageViewModel.RecentPosts = _blogRepository.GetNewestPosts(5); HttpContext.Current.Cache.Add("homepageModel", homepageViewModel, ...); } return View(homepageViewModel); }
什么效果也没有!由于是通过视图中的控制器变量和视图模型中的属性进入数据层,因此并不能提升性能……缓存视图模型并没有什么用处。
试试缓存 MVC 动作的输出吧:
[OutputCache(Duration=2000)] public ActionResult Index() { var homepageViewModel = new HomepageViewModel(); homepageViewModel.RecentPosts = _blogRepository.GetNewestPosts(5); return View(homepageViewModel); }
请注意非常好用的「OutputCache」属性。MVC 支持 ASP.NET 输出缓存,因此请在适当情况下,充分利用这一特点。如需缓存模型,那么模型基本上应为带自动(且只读)属性的 POCO,不能调用其他知识库方法。
另外还想介绍笔者尚未尝试的一个好方法,即采用不同的输出缓存供应商,从而在AppFabric、NOSQL 或其他任何需要的地方进行缓存。MVC 的可扩展性非常强。
5、大胆使用 ORM
如果不好好利用 ORM 的特征集,那真是极大的损失。笔者所检查的代码库中用到了 NHibernate,但是并未真正利用好。本可以用来解决一部分内存问题的 NHibernate高级射影功能完全被忽略了。这一问题有时是因为使用“库模式”所造成的僵化思维,有时则是由于缺乏必要的知识。
与仅仅使用基本的类方法相比,通过利用 EF 或 NHibernate 特征,知识库的功能可以大大增加。它们可以在控制器中形成和返回你真正想要的数据,大大增强控制器的逻辑性。赶紧阅读 ORM 文件,了解一下它可以提供的功能吧,这将使你受益良多。
笔者认为,采用知识库模式,就好比驱除掉雾霾,使明媚的阳光从 ORM 窗口照进来。刚接触 RavenDB 时,笔者丢弃了知识库层(实际上是整个数据项目),在应用服务层中完全使用 Raven 查询,用了一点点扩展方法来重复使用查询逻辑。笔者发现,许多逻辑都明显依赖于特定的上下文,且利用 Raven 的扩展特性进行投射、形成并分批处理查询,大有益处。
那只是你一家之言……
如果你认为可以将 ORM 抽象化,笔者强烈建议你换个角度思考。ORM 确实是抽象概念,如果你认为,由于 ORM 是「抽象」的,所以轻而易举就能用别的 ORM 置换现有的 ORM,那么事实会让你大吃一惊。因为我之前也是这么想的,直到我了解到,转换至 Raven 简直改变了我整个代码库,这是我完全没有预料到的。ORM 不仅仅影响到数据存取,还会影响域以及业务逻辑,甚至会影响用户界面。通过移除知识库抽象,可以切实降低数据存取代码的整体复杂度。
「常识并非人人皆知」
家父常常拿这句话提醒我。有时候,通过仔细查阅代码,也会发现你认为人人皆知的道理,事实并非如此;你可能从实践经验中了解到这一点,或在 google 上读到这一点,就错误地假设这是人人都知道的事实了。
希望这篇文章能帮到需要的人!
OneAPM 助您轻松锁定 .NET 应用性能瓶颈,通过强大的 Trace 记录逐层分析,直至锁定行级问题代码。以用户角度展示系统响应速度,以地域和浏览器维度统计用户使用情况。想阅读更多技术文章,请访问 OneAPM 官方博客。
本文转自 OneAPM 官方博客
原文地址:http://kamranicus.com/blog/2014/01/29/5-tips-to-improve-your-mvc-site/
分享题目:改善ASP.NETMVC代码库的5点建议
本文链接:http://myzitong.com/article/pogood.html