ASP.NET MVC3依赖注入误解
public object GetService(Type serviceType)
{
object resolvedObject = null;
try
{
resolvedObject = _unityContainer.Resolve(serviceType);
}
catch(ResolutionFailedException e) { }
return resolvedObject;
}
这是捕获异常并返回 null 的最佳实践吗？默认情况下，mvc 尝试解析 IControllerFactory 和 IViewPageActivator，即我得到两个捕获的异常。我不喜欢这个解决方案。
我的朋友建议检查 IControllerFactory、IViewPageActivator 上的 serviceType 以及是否引发异常 - 捕获并记录错误。但对我来说 - 这不是最好的解决方案，它就像一种硬编码。
public object GetService(Type serviceType)
{
object resolvedObject = null;
try
{
resolvedObject = _unityContainer.Resolve(serviceType);
}
catch(ResolutionFailedException e) { }
return resolvedObject;
}
Is this best practice to catch exception and return null? By default mvc try to resolve IControllerFactory and IViewPageActivator, i.e. i get two catched exceptions. I don't prefer this solution.
My friend suggest to check serviceType on IControllerFactory, IViewPageActivator and if an exception is raised - catch and logged error. but as for me - it is not best solution, it like kind of hardcode.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
MVC3 的 DependencyResolver 首先是一个服务定位器。它本质上是 MVC 和公共服务定位器 (commonservicelocator.codeplex.com) 的私生子。 CSL 服务定位器和 MVC3 的 DependencyResolver 之间的区别在于，MVC 架构师决定他们需要一种更安全的方法来处理无法通过它解决服务的情况，他们选择的答案是实现在这些情况下，
IDependencyResolver应返回 null。对于 IServiceLocator 的 CSL 实现，标准做法是抛出 ActivationException，它允许使用标准化异常来处理这些情况。
使用 MVC，框架将调用 DependencyResolver 来尝试解析已配置的服务。如果找不到合适的服务，则会使用默认服务。
例如，当它想要查找
IControllerFactory时，它会首先检查DependencyResolver。如果失败，它将使用通过ControllerBuilder.SetControllerFactory(...)配置的DefaultControllerFactory。由于这种检查优先的方法，最好返回 null，然后让容器特定的异常冒泡。这意味着此时您必须捕获/吞掉任何异常，因为 MVC 框架不负责为您处理该异常（责任应该由容器/IDependencyResolver 本身承担）。
您可以在此阶段记录此信息，但 MVC3 的做法是在这些实例中返回 null。
MVC3's
DependencyResolveris a service locator, first and foremost. It is essentially the lovechild of MVC and the Common Service Locator (commonservicelocator.codeplex.com). The differences between a CSL service locator and MVC3'sDependencyResolveris that the MVC architects decided that they needed a safer way of handling cases where services cannot be resolved through it, and the answer they chose was that the implementation ofIDependencyResolvershould return null in these circumstances.With CSL implementations of IServiceLocator, the standard practice is to throw an
ActivationExceptionwhich allows for a standardised exception for handling these cases.With MVC, the framework will call the
DependencyResolverto try and resolve a configured service. If it cannot find a suitable service, it uses a default.E.g., when it wants to find an
IControllerFactory, it will check theDependencyResolverfirst. If it fails there, it will use theDefaultControllerFactoryconfigured throughControllerBuilder.SetControllerFactory(...). Because of this check-first approach, it's better to return null then let a container specific exception bubble up.This means that you must catch/swallow any exception at this point, as it is not MVC framework's responsibility to handle it for you (the onus should be on the container/
IDependencyResolveritself).You could log this at this stage, but the practice with MVC3 is to return null in these instances.
这显然不是最佳实践，但 ASP.NET MVC 的实现方式是，当 IoC 无法解析服务时，它应该返回 null，以便 mvc 框架可以回退到其默认值。请注意，除了控制器/视图工厂之外，还有许多服务依赖于它，因此抛出异常会破坏这些服务的功能。
我在内部 ASP.NET 邮件列表中对设计决策进行了争论，但这就是目前的情况:-(。
This obviously not a best practice, But ASP.NET MVC is implemented in way that when the IoC is not able to resolve a service it should return null, so that the mvc framework can fallback to its default. Pls note there are number of services other than controller/view factory depends on it, so throwing exception will break those from functioning.
I argued with the design decision in the internal asp.net mailing list, but this how it currently stands :-(.
对于 IControllerFactory 你可以
我不确定哪些类实现了 IViewPageActivator 和 ModelMetadataProvider。尽管异常可以被吞噬，但抑制异常并不是一个好的做法，因为一般来说异常会影响性能。一旦发生异常，框架就会填充堆栈跟踪，这需要时间。
For IControllerFactory you can
I am not sure which classes implement IViewPageActivator and ModelMetadataProvider. Event though an exception can be swallowed, supressing exceptions it is not a good practice simply because in general exceptions affect performance. Once an exception is caought the framework populates stack trace which take time.