Generieke modulaire architectuur voor portal site.

[Haan]

Ik ben met een collega bezig met het opzetten van een architectuur voor portal websites die gebruik maken van Dynamics CRM als database. Dit zullen sites zijn die gebouwd worden met ASP.NET MVC.

We willen dit modulair opzetten, zodat je snel een portal neer kan zetten op basis van bepaalde functionele blokken. Een basis portal zal bestaan uit een site waarop je kan inloggen en je eigen gegevens kan inzien / bijwerken. Hier bovenop moeten dus andere modules gebouwd kunnen worden die extra functionaliteit toevoegen.

De basis opzet is een DAL in de vorm van een WCF service waarin communicatie met de database plaatsvindt en conversielogica aanwezig is om Dynamics CRM entiteiten om te zetten naar domain entiteiten. Iedere webservice functie heeft zijn eigen request class en eigen response class (bijv. public GetNawResponse GetNaw(GetNawRequest request). Daarnaast is er dus een class library waarin domain objecten in gedefinieerd worden (Person, Company, Address etc.). Een business logic laag praat met de DAL en wordt aangeroepen vanuit de website.

We lopen nu tegen een paar dingen aan die voornamelijk te maken hebben met het modulair maken van de architectuur, waarvan we ons afvragen of dat niet handiger kan. Wat we nu hebben bedacht is om voor iedere module een aparte DAL te maken met bijhorende business logic laag. Het eerste waar je dan tegen aanloopt, is dat je meerdere WCF services krijgt, die allemaal een eigen web.config nodig hebben (waarin oa. de credentials voor de database staan). Ook heb je dus voor iedere module een aparte BLL.

Ieder BLL project bevat nog een tweede punt dat mij niet helemaal lekker zit. We hebben het nu zo ingericht dat in de BLL weer zijn eigen request - en response classes heeft, deze wrappen de classes uit de WCF service. Reden hiervoor is dat het dan mogelijk is om in de business laag extra logica kwijt te kunnen, maar het kan ook zo zijn dat het gewoon 1-op-1 doorgestuurd kan worden. Ieder BLL project heeft zijn eigen 'manager' waarmee je functionaliteit aan kan roepen, bijvoorbeeld:

C#:

public class NawManager
{
    private readonly INaw _dal;
    public NawManager(INaw service)
    {
        _dal = service;
    }

    public GetNawBlResponse GetNaw(GetNawBlRequest blRequest)
    {
        var request = new GetNawRequest {ApiKey = blRequest.ApiKey, UserName = blRequest.UserName};

        var response = _dal.GetNaw(request);

        return new GetNawBlResponse(response);
    }
}

We hebben nu een opzet gemaakt met de basis (NAW) functionaliteit en een tweede module en hoewel dat opzich wel werkt, zijn we benieuwd naar ervaringen van anderen en eventuele tips om dingen beter te kunnen doen, want het voelt nu alsof we niet alles even handig aanpakken.

[P_de_B]

Niet een heel uitgebreid antwoord, maar ik denk dat ook je even moet zoeken op Dependency Injection als je het hebt over een modulaire architectuur. Voor .Net zijn verschillende tools hiervoor beschikbaar, wij gebruiken bijvoorbeeld http://ninject.org/

Stop writing monolithic applications that make you feel like you have to move mountains to make the simplest of changes. Ninject helps you use the technique of dependency injection to break your applications into loosely-coupled, highly-cohesive components, and then glue them back together in a flexible manner.

[Haan]

Dependency injection obv Ninject zit er al in
Onderstaande functie wordt aangeroepen in de Test GUI site global.asax Application_Start():

C#:

public void SetupDependencyInjection()
        {
            IKernel kernel = new StandardKernel();

            kernel.Bind<INaw>().To<NawClient>();
            kernel.Bind<NawManager>().To<NawManager>();

            DependencyResolver.SetResolver(new NinjectDependencyResolver(kernel));
        }

Nu moet ik wel heel eerlijk zeggen dat het hele IoC gebeuren nog een beetje vaag is wat betreft het nu eigenlijk precies doet / hoe je het nuttig kunt gebruiken. Heb je daar misschien een link voor met uitleg?

[ Voor 27% gewijzigd door Haan op 15-12-2011 13:50 . Reden: code voorbeeld wat aangepast ]

[Haan]

Niemand die hier verder iets zinnigs over te zeggen heeft?

Intussen nog wel ontdekt dat we in de business laag het 'decorator' pattern hebben toegepast zonder het zelf te weten

[Verwijderd]

Waarom kies je voor een Request/Response architectuur en niet voor een event driven architectuur (cqrs).

Het lijkt me dat als je DAL voornamelijk uit wcf services gaan bestaan, je op den duur performance / scalability issues gaat krijgen.

[denyos]

Voor wat betreft de multiple web.config settings zou je nog kunnen kijken naar web.config includes.
Meer informatie hierover is te lezen op: http://learn.iis.net/page...configuration/#ConfigFile

Nog steeds niet ideaal, maar dan hoef je je configuraties in ieder geval maar op 1 plek te wijzigen.

[Haan]

Verwijderd schreef op woensdag 28 december 2011 @ 14:23:
Waarom kies je voor een Request/Response architectuur en niet voor een event driven architectuur (cqrs).

Het lijkt me dat als je DAL voornamelijk uit wcf services gaan bestaan, je op den duur performance / scalability issues gaat krijgen.

Ik heb nog wel gekeken naar wat cqrs inhoudt, maar mijn indruk is dat het niet veel wordt gebruikt, ofwel omdat het nog nieuw is, ofwel om andere redenen, maar dan kies ik liever voor een architectuur die ik wel ken (sowieso wast het op dat moment al te laat om voor een compleet andere architectuur te kiezen ). Maar voor een volgende keer wellicht iets om nog eens naar te kijken.

denyos schreef op dinsdag 03 januari 2012 @ 13:58:
Voor wat betreft de multiple web.config settings zou je nog kunnen kijken naar web.config includes.
Meer informatie hierover is te lezen op: http://learn.iis.net/page...configuration/#ConfigFile

Nog steeds niet ideaal, maar dan hoef je je configuraties in ieder geval maar op 1 plek te wijzigen.

Hebben we geprobeerd, maar we kregen het niet voor elkaar om een losse appSettings file uit te lezen buiten de eigen folder van de web applicatie.

Maar wat ik eigen wilde melden is dat mij opeens dé oplossing voor het BLL probleem te binnen schoot: partial classes! Stom dat we daar niet eerder aan hebben gedacht. Je kan daar prima de request/response classes uit de WCF services uitbreiden in de business laag, zonder dat je in de uiteindelijke clients te maken krijgt met specifieke BLL request en response classes

Dus het plaatje is nu als volgt:
WCF service (interface) -> BLL interface (implementeert service interface, definieert extra functies, breidt bestaande uit) -> client

[Hooiopdevork]

Haan schreef op donderdag 15 december 2011 @ 12:33:
Nu moet ik wel heel eerlijk zeggen dat het hele IoC gebeuren nog een beetje vaag is wat betreft het nu eigenlijk precies doet / hoe je het nuttig kunt gebruiken. Heb je daar misschien een link voor met uitleg?

Hier heb je enkele bruikbare links:

http://www.mikesdotnettin...-Control-with-ASP.NET-MVC

http://www.codeproject.co...of-control-and-Dependency

[Compuhair]

Begrijp ik het goed dat je voor iedere DAL een apart project onder je solution in Visual Studio hebt gehangen?
Dus een project voor "DAL Naw" en een project voor bijv. "DAL Dossier" etcetera?