在这部分的教程中,您将查看自动生成的Detail方法和Delete方法。
打开Movie控制器,查看Detail方法
public ActionResult Details(int id = 0) { Movie movie = db.Movies.Find(id); if (movie == null) { return HttpNotFound(); } return View(movie); }
代码先行(Code First)使用Find方法可以很容易地找到数据。方法内置了一个重要的安全点,即在代码试图处理影片记录之前,确保Find方法找到一条影片记录。例如,黑客可以通过修改地址,由http://localhost:xxxx/Movies/Details/1 修改为http://localhost:xxxx/Movies/Details/12345(或者其他在实际影片库中不存在的参数值),从而引发错误。如果你不检查影片是否为空,将会导致检索数据库出错。
查看Delete方法和DeleteConfirmed的方法
// // GET: /Movies/Delete/5 public ActionResult Delete(int id = 0) { Movie movie = db.Movies.Find(id); if (movie == null) { return HttpNotFound(); } return View(movie); } // // POST: /Movies/Delete/5 [HttpPost, ActionName("Delete")] public ActionResult DeleteConfirmed(int id) { Movie movie = db.Movies.Find(id); db.Movies.Remove(movie); db.SaveChanges(); return RedirectToAction("Index"); }
需要注意的是HTTP GET Delete方法不删除指定的影片,它返回一个Movie的视图,您可以执行(HttpPost)删除方法来完成删除操作。在一个GET请求的响应(对于这个问题,执行编辑操作,创建操作,或任何其他更改数据的操作)执行删除操作,带来了一个安全漏洞。欲了解更多信息,请参阅斯蒂芬•瓦尔特的的博客条目ASP.NET MVC Tip #46 — Don't use Delete Links because they create Security Holes(不要使用删除链接,因为它们会导致安全漏洞)。
删除数据的HttpPost方法,被命名为DeleteConfirmed。
公共语言运行库(CLR)需要重载方法有一个独特的签名(相同的方法名,但不同的参数列表)。然而,在这里,你需要删除方法GET和POST 都具有相同的签名。它们都需要接受一个整数作为参数。
为了解决该问题,有几种方法可以选择。其中一种方法是,赋予方法不同的名称。这就是脚手架机制在前面的例子所做的事情。然而,这引入了一个小问题:ASP.NET映射url各部分来执行方法,如果你重命名一个方法,路由通常将无法找到该方法。解决的办法就是你看到的例子中所做的,即为DeleteConfirmed方法添加ActionName("Delete")属性。这将影响到路由系统,包含/ Delete / URL的 POST请求会调用DeleteConfirmed的方法。
避免具有相同的名称和签名的方法发生问题,另一种常见的方式是人为地改变Post方法的签名,使其包含未使用的参数。例如,一些开发人员的增加传递给Post方法类型为FormCollectionPOST的参数而不使用该参数:
public ActionResult Delete(FormCollection fcNotUsed, int id = 0) { Movie movie = db.Movies.Find(id); if (movie == null) { return HttpNotFound(); } db.Movies.Remove(movie); db.SaveChanges(); return RedirectToAction("Index"); }
结束语
现在您拥有了一个将数据存储在本地DB数据库的完整的ASP.NET MVC应用程序。您可以创建,读取,更新,删除和搜索电影。
译者注:原文整个教程已翻译完毕,第一次做翻译工作,不足之处望大家多多包含。翻译过程比较仓促,十篇文章完成后,从头到尾进行了一遍校对,增加目录和索引,改正了错别字,并把一些别扭的直译修改为意译。下一步的计划,在这个例子的基础上,进一步深入摸索和研究。
译文地址:http://www.cnblogs.com/seawaving/archive/2012/12/10/2811064.html