.net – 扩展/插件通信的体系结构
一旦解决了加载插件的问题(在.NET中通过MEF),下一步要解决的是与它们的通信.简单的方法是实现一个接口并使用插件实现,但有时插件只需要扩展应用程序的工作方式,并且可能有很多扩展点.
我的问题是如何处理这些扩展点.我已经看到了不同的方法,但我不确定每个方法的优点和缺点,以及是否有更多更好的方法来实现这一点: >事件:将静态事件添加到我们想要“扩展”的所有内容中.例如,如果我想为User类添加自定义验证,我可以添加一个OnValidation静态事件处理程序,并在构建时从插件添加事件. 你有没有使用过暴露的方法之一?哪一个最适合你? 在您提出要求之前,我们的应用程序是一个可扩展的核心(用户,rola和内容管理),以构建我们的客户端特定的以内容为中心的Web应用程序.一切都建立在ASP.NET MVC之上. 解决方法
您的设计决策的关键是分析并清楚地了解插件彼此之间的差异.
例如.在处理静态事件时,您可能必须将每个事件定义为某种形式的令牌,枚举,对象等.为每个插件定义一组新事件自然会对您的整个设计起作用,特别是在松散耦合和重用. 如果您的插件非常不同,您可能会受益于拥有总线/消息传递体系结构,因为在这种情况下您可以引入插件可以订阅的域/类别的通信交换.即一系列事件和消息可以在某个兴趣域中.请注意,某个类别内的通信仍然可以使用静态事件,因此这两个备选方案并不相互排斥. 根据我的经验,插件实现的直接接口是插件架构最严格的方法.扩展插件接口通常意味着插件和提供程序的代码修改.你需要有一个坚实的通用接口,你知道你的应用程序可以存在很长一段时间. 通过将设计分解为两个方面 – 通信通道和协议,您可能更容易处理设计.静态事件处理是一个协议问题,而总线消息传递和直接接口是一个通道问题. 一般来说,我会说协议是最难从一开始就正确设计的,因为你可能没有一般的感觉,你可以画出一般或特定的线条. 编辑:Lars在他的评论中提到了一个重点 – 如果您的平台支持异常,您可以在使用直接接口时集中大量错误处理,从而减轻插件必须处理通用错误并可能超出其特定域的错误(例如“插件加载错误”或“文件打开失败”).但是,如果每次添加插件时都必须维护接口,这些好处似乎会消失.最糟糕的情况是接口开始变得不一致,因为你从一开始就没有意识到它们应该支持什么.当已经构思了大量插件时,重构整个界面设计并不是一件容易的事. (编辑:李大同) 【声明】本站内容均来自网络,其相关言论仅代表作者个人观点,不代表本站立场。若无意侵犯到您的权利,请及时与联系站长删除相关内容! |
- asp.net-web-api – ASP.NET Web API避免查询字符串中的无效
- .net – SqlMembershipProvider与自定义解决方案
- asp.net-mvc – 我可以从HttpContext获取控制器吗?
- asp.net – Web部署项目构建不再属于项目的文件
- azure – 错误System.BadImageFormatException服务结构
- asp.net-mvc – ASP.NET MVC区域可以显示自己的错误页面集吗
- BreezeJS vs JayData for ASP开发ASP.NET MVC
- 优化 .net core 应用的 dockerfile
- asp.net-mvc – MVC3 ModelBinding回收了一个带有索引间隙的
- asp.net-web-api – 从OWIN中间件更改响应对象