在 Web 应用程序中何处以及如何使用拦截器？

发布于 2024-11-29 18:48:12 字数 228 浏览 4 评论 0原文

我最近对拦截器概念很感兴趣。我知道这个概念在 NHibernate、Entity Framework 等许多库中都有使用。但我对如何在 ASP.NET MVC Web 应用程序中使用这个概念感兴趣。

在 Mvc Web 应用程序中什么地方有用？

有没有使用拦截器的开源 Asp.Net Mvc 项目？

Asp.net Mvc 已经支持一种带有过滤器的控制器拦截器。使用过滤器而不是拦截器更好？

原文

分享到QQ

分享到微博

如果你对这篇内容有疑问，欢迎到本站社区发帖提问参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。

发布评论

需要登录才能够评论，你可以免费注册一个本站的账号。

世态炎凉 2024-12-06 18:48:12

何时/何时使用拦截器

查看您之前开发的应用程序并检查代码。查找在方法和属性的开头或结尾处经常重复的代码。您可以考虑将这段代码从所有这些方法移至拦截器中。例如，我注意到许多执行输入验证的 MVC 操作都使用相同的几行代码来执行此操作：

if (!ModelState.IsValid)
    return View(model);

这些代码可能会被移动到拦截器（在本例中可能是 MVC 过滤器）。编写和应用过滤器的成本是否超过了重复代码的成本？（2 行代码乘以使用此代码的控制器操作数）。在这种情况下，也许不是。然而，在其他情况下，使用拦截器的好处会更大。

以下列出了我认为可能会发生此类代码重复的一些情况，即闻起来好像可以从拦截器中受益的场景：

输入验证 >（如上图所示）。
调试日志记录。您可以编写拦截器记录每个方法调用的进入和退出。
线程同步。您的问题是关于 Web 应用程序的，但如果您正在开发具有 MVP 样式视图的 Windows 应用程序，您可以应用一个拦截器来确保所有方法调用都同步回 UI 线程。
数据库事务。我的大多数数据库事务代码如下所示

：

using (var transaction = Session.BeginTransaction())
{
    // ... do some work that is unique to this method ...
    transaction.Commit();
}

PropertyChanged 事件实现。此代码通常非常重复并且写起来很烦人。 Sacha Barber 彻底探索了如何使用各种框架自动实现此事件< /a>.
安全性。您的应用程序中可能有许多方法应仅限于某些用户。 AuthorizeAttribute正是针对这一点的过滤器。
Web 服务请求限制。某些 API（例如 Basecamp 的 API）要求您将您的请求限制在给定时间范围内的一定数量的请求。如果您编写了 Basecamp 客户端类，则可以对其应用拦截器，以确保所有方法调用都遵守速度限制，并在必要时使用 Thread.Sleep。
结果缓存。 MVC 有一些为此目的预先构建的过滤器。您可以编写自己的拦截器来缓存 UI 层下面的层的结果。
WCF 错误处理。如果 WCF 客户端处于 Faulted 状态，则无法Dispose，因此每个创建和销毁实例的方法客户端需要检查状态，然后在必要时调用 Abort，而不是简单地在客户端周围包装 using 子句。在这种情况下，拦截器可能不是最合适的。修复 Dispose< 可能更容易/code> 实现或使用某种包装器。

上述示例是否适合拦截器取决于您的应用程序的独特复杂性。当然，这个清单并不详尽，也不可能详尽。拦截器的可能应用程序与您编写的应用程序一样多种多样。

如何使用拦截器

我可以想到您可能希望应用拦截器的三个主要位置：控制器、服务和域对象。

对于 MVC 控制器，继续使用 MVC 的过滤器。
对于从 IoC 容器中提取的中间层服务，过滤器不是一个选项（因为它不是控制器），因此您应该使用 IoC 容器的拦截功能。
对于您通常使用构造函数直接实例化（如果它是新实体）或从您选择的 ORM 获取（如果它是现有实体）的域对象，您需要使用某种排序对象工厂而不是构造函数和指导您的 ORM 如何使用工厂。

有关如何完成所有这些的具体细节取决于您使用的工具。

Where/when to use interceptors

Take a look at a previous application you've developed and examine the code. Look for code that is frequently duplicated at the beginning or end of methods and properties. This is code that you may consider moving from all of those methods into an interceptor. For example, I've noticed that many of my MVC actions that perform input validation do so with same same couple lines of code:

if (!ModelState.IsValid)
    return View(model);

This is code that could potentially be moved to an interceptor (probably an MVC filter in this case). Does the cost of writing and applying the filter outweigh the cost of this duplicated code? (2 lines of code times the number of controller actions using this). In this case, perhaps not. There are other situations, however, where the benefit of using an interceptor would be greater.

Here's a list of some situations where I imagine this type of code duplication might occur, i.e. scenarios that smell like they could benefit from interceptors:

Input validation (as illustrated above).
Debug logging. You could write an interceptor that records the entrance and exit of every method call.
Thread synchronization. Your question is about web apps, but if you're developing a Windows application with an MVP style view, you could apply an interceptor that ensures that all method calls are synchronized back to the UI thread.
Database transactions. Most of my database transaction code looks like this:

using (var transaction = Session.BeginTransaction())
{
    // ... do some work that is unique to this method ...
    transaction.Commit();
}

PropertyChanged event implementations. This code is usually very repetitive and annoying to write. Sacha Barber has thoroughly explored how to automatically implement this event using various frameworks.
Security. There are probably many methods in your application that should be restricted to only certain users. The AuthorizeAttribute is a filter for exactly this.
Web service request throttling. Some API's, such as the API for Basecamp, ask that you limit your requests to a certain number of requests per a given timeframe. If you wrote a Basecamp client class, you could apply an interceptor to it to ensure that all the method calls honored the speed limit, using Thread.Sleep when necessary.
Result caching. MVC has some filters pre-built for this purpose. You could write your own interceptor to cache results for layers underneath the UI layer.
WCF error handling. You can't Dispose a WCF client if it's in the Faulted state, so every method that creates and destroys an instance of the client needs to check the state, then call Abort if necessary instead of simply wrapping a using clause around the client. An interceptor might not be the best fit in this case. It's probably easier to just fix the Dispose implementation or use some kind of wrapper.

Whether or not the above examples would be good candidates for interceptors depends on the unique intricacies of your application. This list of course is not exhaustive, nor can it be. The possible applications of interceptors are as varied as the applications you write.

How to use interceptors

I can think of three primary places where you might like to apply an interceptor: Controllers, Services, and Domain objects.

With an MVC controller, it makes the most sense to go ahead and use MVC's filters.
For a middle-tier service that you would pull out of your IoC container, filters are not an option (because it's not a controller), so you should use the interception features of your IoC container.
For your domain objects that you typically either instantiate directly with a constructor (if it's a new entity) or fetch from your ORM of choice (if it's an existing entity), you'll need to use some sort of object factory instead of the constructor and instruct your ORM how to use the factory.

The nitty gritty details about how to accomplish all of this will depend on which tools you are using.

回复收藏 0 原文