Enterprise Library In-depth analysis and flexible application (3): If the unity, PIAB, Exception Ha

Enterprise Library In-depth analysis and flexible application (3): If unity, PIAB, Exception handling into the MVP model

Recently in the project of making a smart Client Software factory. Those familiar with SCSF or cabs should have a clear idea of the MVP design pattern. MVP is a variant of MVC, view and mode focus on the UI rendering and business model, view and mode are completely separated, view through presenter implementation of the business model access, presenter "indirect" call view implementation of the UI operation. For the MVP exception handling, we are directly through the Enterprise Library exception handling Application block to achieve. You add the Try/catch block to the event for each control in the view, and you implement the handling of the exception through Exceptionpolicy in the catch. The problem that this leads to is that the same code repeats itself across all corners of the application, so I have the idea: through the policy injection in an AOP way to deal with the exception, when the idea, I think a step more, why not unity also integrated in.

First, the MVP introduction

To allow readers who have not been in touch with the MVP to understand what's going on, I'll make a simple introduction to the MVP. As the following illustration shows: The MVP is a bit like our familiar MVC, view is responsible for implementing UI rendering has been interacting with the user, in the cab, view is generally implemented by a user control, mode focus on the specific business model, independent of view and presenter. View has a presenter reference that accesses mode through presenter when the view needs to call mode (for example, if you need access to the mode incoming query condition to get the data). For presenter, it needs to operate on the view (such as when the data is successfully fetched and displayed in view), but presenter does not refer directly to the view itself, but to the view's interface (IView), so view The image is an unstable object, and presenter only needs some fixed operations in view, so defining these operations in iview interface translates the reliance on view to iview dependence, which also fully embodies the principle of structure-oriented change.

Second, simulate the simple MVP

Next we simulate the MVP with a simple scenario. This is an example of my commonly used calculator, and the overall composition is shown in the following illustration:

1, Icalculator:calculator interface, defines an operation for division operations

namespace Artech.UnityInMVP
{
　　public interface ICalculator
　　 {
　　　　int Divide(int op1, int op2);
　　}
}

2, Calculator: The implementation of the ICalculator interface

namespace Artech.UnityInMVP
{
　　public class Calculator:ICalculator
　　{
　　　　public　 int Divide(int op1, int op2)
　　　　{
　　　　　　return op1 / op2;
　　　　}
　　}
}