Architektura Plug-in dla ASP.NET MVC

Pracuję nad frameworkiem rozszerzalności do wykorzystania na ASP.NET MVC. Mój Framework rozszerzalności jest oparty na słynnym kontenerze IOC: Structuremap .

Przypadek użycia, który staram się spełnić jest prosty: stworzyć aplikację, która powinna mieć kilka podstawowych funkcji, które można rozszerzyć dla każdego klienta (=multi-tenancy). Powinna istnieć tylko jedna instancja aplikacji hostowanej, ale ta instancja może być dostosowana dla każdego klienta bez wprowadzania żadnych zmian w Strona główna.

Wtyczka jest po prostu asselmbly, który zawiera kontrolery, repozytoria lub obiekty domeny, które przestrzegają określonej konwencji nazewnictwa. Konwencja nazewnictwa jest prosta, każda klasa powinna być poprzedzona przez customerID, np.: AdventureworksHomeController.

Aby rozszerzyć aplikację należy skopiować plug-in assembly w folderze extension aplikacji. Gdy użytkownik zażąda strony w folderze głównym klienta np.: http://multitenant-site.com/[customerID] / [controller] / [action] framework sprawdza, czy istnieje wtyczka dla tego konkretnego klienta i tworzy instancje niestandardowych klas wtyczek, w przeciwnym razie ładuje domyślny raz. Klasami niestandardowymi mogą być Kontrolery-repozytoria lub obiekty domeny. Takie podejście umożliwia rozszerzenie aplikacji na wszystkich poziomach, od bazy danych po interfejs użytkownika, poprzez model domeny, repozytoria.

Kiedy chcesz rozszerzenie niektórych istniejących funkcji tworzysz wtyczkę złożoną, która zawiera podklasy podstawowej aplikacji. Kiedy musisz stworzyć zupełnie nowe funkcje, dodajesz nowe kontrolery wewnątrz wtyczki. Kontrolery te zostaną załadowane przez framework MVC, gdy wymagany jest odpowiedni adres url. Jeśli chcesz rozszerzyć interfejs użytkownika, możesz utworzyć nowy widok wewnątrz folderu rozszerzenia i odwołać się do niego za pomocą nowego lub podklasowanego kontrolera .aby zmodyfikować istniejące zachowanie, możesz utworzyć nowy repozytoria lub obiekty domeny lub podklasy wychodzące z nich. Zadaniem frameworka jest określenie, który kontroler / repozytorium / obiekt domeny powinien zostać załadowany dla konkretnego klienta.
Radzę rzucić okiem na structuremap (http://structuremap.sourceforge.net/Default.htm ), a szczególnie w funkcji rejestru DSL http://structuremap.sourceforge.net/RegistryDSL.htm .

Jest to kod, którego używam przy starcie aplikacji do rejestracji wszystkich plug-in controllers / repozytoria or domain objects:

protected void ScanControllersAndRepositoriesFromPath(string path)
        {
            this.Scan(o =>
            {
                o.AssembliesFromPath(path);
                o.AddAllTypesOf<SaasController>().NameBy(type => type.Name.Replace("Controller", ""));
                o.AddAllTypesOf<IRepository>().NameBy(type => type.Name.Replace("Repository", ""));
                o.AddAllTypesOf<IDomainFactory>().NameBy(type => type.Name.Replace("DomainFactory", ""));
            });
        }

Używam również rozszerzenia dziedziczącego z systemu.Www.MVC. DefaultControllerFactory. Ta fabryka jest odpowiedzialna za załadowanie obiektów rozszerzenia(kontrolerów/rejestrów lub obiektów domeny). Możesz podłączyć własne fabryki, rejestrując je przy starcie w globalnym.plik asax:

protected void Application_Start()
        {
            ControllerBuilder.Current.SetControllerFactory(
                new ExtensionControllerFactory()
                );
        }

Ten framework jako w pełni funkcjonalny Przykładowy obiekt można znaleźć na: http://code.google.com/p/multimvc/

Więc trochę pobawiłem się przykładem z J Wynia powyżej. Wielkie dzięki za to btw.

Zmieniłem rzeczy tak, że rozszerzenie VirtualPathProvider używało statycznego konstruktora do tworzenia listy wszystkich dostępnych zasobów kończących się na.aspx w różnych bibliotekach dll w systemie. To żmudne, ale robimy to tylko raz.

To chyba totalne nadużycie sposobu, w jaki mają być używane również pliki wirtualne; -)

Kończysz z a:

Private static IDictionary resourceVirtualFile;

Ciąg znaków jest ścieżkami wirtualnymi.

Poniższy kod przyjmuje pewne założenia dotyczące przestrzeni nazw .pliki aspx, ale będzie działać w prostych przypadkach. Fajną rzeczą jest to, że nie musisz tworzyć skomplikowanych ścieżek widoków, które są tworzone z nazwy zasobu.

class ResourceVirtualFile : VirtualFile
{
    string path;
    string assemblyName;
    string resourceName;

    public ResourceVirtualFile(
        string virtualPath,
        string AssemblyName,
        string ResourceName)
        : base(virtualPath)
    {
        path = VirtualPathUtility.ToAppRelative(virtualPath);
        assemblyName = AssemblyName;
        resourceName = ResourceName;
    }

    public override Stream Open()
    {
        assemblyName = Path.Combine(HttpRuntime.BinDirectory, assemblyName + ".dll");

        Assembly assembly = Assembly.ReflectionOnlyLoadFrom(assemblyName);
        if (assembly != null)
        {
            Stream resourceStream = assembly.GetManifestResourceStream(resourceName);
            if (resourceStream == null)
                throw new ArgumentException("Cannot find resource: " + resourceName);
            return resourceStream;
        }
        throw new ArgumentException("Cannot find assembly: " + assemblyName);
    }

    //todo: Neaten this up
    private static string CreateVirtualPath(string AssemblyName, string ResourceName)
    {
        string path = ResourceName.Substring(AssemblyName.Length);
        path = path.Replace(".aspx", "").Replace(".", "/");
        return string.Format("~{0}.aspx", path);
    }

    public static IDictionary<string, VirtualFile> FindAllResources()
    {
        Dictionary<string, VirtualFile> files = new Dictionary<string, VirtualFile>();

        //list all of the bin files
        string[] assemblyFilePaths = Directory.GetFiles(HttpRuntime.BinDirectory, "*.dll");
        foreach (string assemblyFilePath in assemblyFilePaths)
        {
            string assemblyName = Path.GetFileNameWithoutExtension(assemblyFilePath);
            Assembly assembly = Assembly.ReflectionOnlyLoadFrom(assemblyFilePath);  

            //go through each one and get all of the resources that end in aspx
            string[] resourceNames = assembly.GetManifestResourceNames();

            foreach (string resourceName in resourceNames)
            {
                if (resourceName.EndsWith(".aspx"))
                {
                    string virtualPath = CreateVirtualPath(assemblyName, resourceName);
                    files.Add(virtualPath, new ResourceVirtualFile(virtualPath, assemblyName, resourceName));
                }
            }
        }

        return files;
    }
}

Możesz zrobić coś takiego w rozszerzonym VirtualPathProvider:

    private bool IsExtended(string virtualPath)
    {
        String checkPath = VirtualPathUtility.ToAppRelative(virtualPath);
        return resourceVirtualFile.ContainsKey(checkPath);
    }

    public override bool FileExists(string virtualPath)
    {
        return (IsExtended(virtualPath) || base.FileExists(virtualPath));
    }

    public override VirtualFile GetFile(string virtualPath)
    {
        string withTilda = string.Format("~{0}", virtualPath);

        if (resourceVirtualFile.ContainsKey(withTilda))
            return resourceVirtualFile[withTilda];

        return base.GetFile(virtualPath);
    }

Myślę, że można zostawić swoje poglądy w projektach wtyczek.

To mój pomysł: potrzebujesz ViewEngine, który wywołałby wtyczkę (prawdopodobnie przez interfejs) i zażądał widoku (IView). Wtyczka utworzy wtedy instancję widoku nie poprzez swój adres url (jak robi to zwykły ViewEngine - / Views/Shared / View.asp), ale poprzez nazwę widoku) np. poprzez reflection lub di / IoC container).

Powrót widoku w wtyczce może mi się nawet (prosty przykład poniżej):

public IView GetView(string viewName)
{
    switch (viewName)
    {
        case "Namespace.View1":
            return new View1();
        case "Namespace.View2":
            return new View2();
        ...
    }
}

...to był tylko pomysł, ale mam nadzieję, że może się udać lub po prostu być dobrą inspiracją.

Ten post może się trochę spóźnić, ale bawiłem się z ASP.NET MVC2 i wymyślili prototyp używając funkcji "obszary".

Oto link dla wszystkich zainteresowanych: http://www.veebsbraindump.com/2010/06/asp-net-mvc2-plugins-using-areas/

[posting as an answer because I can ' t comment]

Świetne rozwiązanie-użyłem podejścia J Wynia i dostałem go do renderowania widoku z osobnego montażu. Jednak takie podejście wydaje się, że renderuje tylko widok. Kontrolery wewnątrz wtyczki nie wydają się być obsługiwane, prawda? Na przykład, jeśli Widok z wtyczki zrobił post, kontroler widoków wewnątrz wtyczki będzie , a nie będzie nazywany. Zamiast tego zostanie przekierowany do kontrolera wewnątrz root MVC application . Czy dobrze to rozumiem, czy istnieje obejście tego problemu?