5
플러그인을로드하는 문제가 해결되면 (.NET에서 MEF까지), 해결할 다음 단계는 그와의 통신입니다. 간단한 방법은 인터페이스를 구현하고 플러그인 구현을 사용하는 것입니다.하지만 플러그인이 애플리케이션의 작동 방식을 확장해야 할 때도 있고 확장 점이 많이 필요할 수도 있습니다.확장/플러그인 통신을위한 아키텍처
내 질문은 그 확장 포인트를 다루는 방법에 관한 것입니다. 나는 그것을하는 다른 방법을 보았으나 각각의 장점과 단점에 대해 잘 모르겠다. 그리고 이것을 성취 할 더 좋은 방법이 더 있다면 :
- 이벤트 : 모든 물건에 정적 이벤트 추가 우리는 "확장 가능"하게 만들고 싶습니다. 예를 들어, User 클래스에 대한 사용자 지정 유효성 검사를 추가하려면 OnValidation 정적 이벤트 처리기를 추가하고 플러그인이 생성 될 때 플러그 인에서 이벤트를 이벤트에 추가 할 수 있습니다.
- 메시지 : 버스와 메시지가 있습니다. 플러그인은 특정 메시지를 구독하고 다른 클래스가 해당 메시지를 게시 할 때 처리 할 수 있습니다. 메시지에는 플러그인이 작동 할 수있는 컨텍스트가 있어야합니다. 유효성 검사의 경우 논리 계층은 UserValidation 메시지를 게시하고 메시지가 수신되면 플러그인이 작동합니다.
- 인터페이스 : 호스트 응용 프로그램은 특정 인터페이스를 구현하는 모든 플러그인을 호출하고 현재 작업의 컨텍스트를 제공합니다. 유효성 검사의 경우, 플러그인은 유효성 검사 (개체 컨텍스트) 메서드를 사용하여 IValidator 또는 IUserValidator를 구현할 수 있습니다.
노출 된 접근 방법 중 하나를 사용해 본 적이 있습니까? 어느 것이 당신에게 가장 잘 맞았습니까?
당신이 물어보기 전에, 우리의 응용 프로그램은 클라이언트 특정 콘텐츠 중심의 웹 응용 프로그램을 빌드 할 수있는 확장 가능한 핵심 (사용자, rola 및 콘텐츠 관리)입니다. 모든 것이 ASP.NET MVC를 기반으로합니다.
인터페이스는 아마도 내 접근 방식 일 것입니다.하지만 응용 프로그램에 따라 다르지만 플러그인 요구 사항이 있습니다. 하지만 플러그인을 작성하는 것은 매우 깨끗한 방법이며 플러그인에서 예외를 쉽게 분리 할 수도 있습니다. –