Doorgaan naar hoofdcontent

Vertaling applicatie lagen in solutions

In het artikel Applicatie architectuur heb ik de diverse lagen behandeld waaruit een applicatie kan bestaan. In dit artikel vertaal ik deze lagen in aparte Visual Studio solutions.

Zoals zichtbaar in onderstaande tabel is iedere applicatie laag een aparte solution geworden. In de betreffende solution staat alleen functionaliteit die in de betreffende laag thuis hoort. Voor de presentatie laag heb ik voorbeeld uitwerkingen opgenomen voor een ASP.net website, een Windows applicatie en een Console applicatie.

Solution Map
       
src      
  _SharedAssemblies    
    EntLib_4_1  
  ApplicationA    
    Presentation.WebAppUI  
      ClientScripts
      CustomControls
      Images
      Pages
      Resources
      Styles
      UserControls
      Utilities
    Presentation.WinAppUI  
      Forms
      Resources
      UserControls
      Utilities
    Presentation.ConsoleUI  
    Services.Interfaces  
    Services.MessageTypes  
    Business.ApplicationFacade  
    Business.Workflow  
    Business.Components  
    Business.Entities  
    Data.AccessComponents  
    Data.DataHelpers  
    Data.ServiceAgents  
    OperationalManagement  
      Caching
      ConfigurationManagement
      ExceptionManagement
      Logging
    UnitTests  
  ApplicationB    

 

De map _SharedAssemblies bevat alle assemblies, met uitzondering van het .NET framework, waarnaar gereferereerd wordt in de code. De gedachte hierachter is dat de code altijd gecompileerd dient te kunnen worden, bijvoorbeeld op een build server, zonder een aparte installatie van de benodigde componenten. Op deze manier wordt er ook voor gezorgd dat altijd met de juiste versie van deze componenten wordt gewerkt. In de tabel is als voorbeeld opgenomen Enterprise Library 4.1 van de Patterns & Practices groep van Microsoft.

Labels:

Reacties

Een reactie posten

Populaire posts van deze blog

Bevindingen over de E-tech ADWG02 tot nu toe

Ik heb de E-tech ADWG02 nu bijna een week in gebruik. Dit is de vervangende modem voor de buggy Linksys WAG54G die ik eerder gekocht had. Mijn bevindingen over de E-tech tot nu toe: Geen crashes tot nu toe. De firmware lijkt op dat punt stabiel. Het apparaat is niet door middel van een knop aan of uit te zetten. Erg vervelend omdat ik het apparaat alleen uit kan zetten door de stekker uit het stopcontact te halen. De reden dat ik hem graag uit wil kunnen zetten is dat het apparaat in de woonkamer staat (in het zicht) en de lampjes nogal fel schijnen. Dat vind ik niet erg prettig. Daarnaast wil ik niet dat de verbinding de gehele dag open staat uit beveiligingsoverwegingen en vanwege het stroomverbruik. WIFI is middels een setting uit te zetten. Als je de setting uitvinkt en bevestigd door middel van een 'apply' zie je het lampje uitgaan op de ADSL modem. Er is op dat moment ook geen WIFI verbinding actief. Sla je de setting definitief op dan reboot de modem automat...
Een reactie posten
Meer lezen

Active Directory limieten

Zoals ieder systeem heeft Active Directory ook zijn limieten. Tijdens wat Active Directory research kwam ik het volgende Technet artikel tegen waarin deze worden benoemd: Active Directory Maximum Limits . Kort samengevat zijn de limieten: Maximum aantal objecten per domain controller in een forest : ongeveer 2,5 biljoen (gedurende de volledige levensduur). Maximum aantal security identifiers (SID's) per domein : ongeveer 1 biljoen (gedurende de volledige levensduur). Aantal groepen waarvan een security indentifier (persoon, groep, computer account) lid kan zijn : ongeveer 1.015 groepen. FQDN lengte limiet : maximum lengte is 64 tekens (dit is inclusief punten en mintekens) voor de fully qualified domain name (FQDN). Bestandsnaam limiet : Windows kent een pad lengte limiet van 260 tekens. Deze is ook van toepassing op de fysieke bestanden van AD zoals SYSVOL. Organisational unit limiet : maximum lengte is 64 tekens. Heeft te maken met de Windows limiet van 260 tekens die in de gaten...
Een reactie posten
Meer lezen

Applicatie architectuur

Een gangbare architectuur voor het opdelen van applicatie functionaliteit is die van het groeperen van functionaliteit naar aandachtsgebied. Onderstaande afbeelding geeft de plaat weer die de Patterns & Practices groep van Microsoft hiervoor gebruikt binnen hun Microsoft Application Architecture Guide (2nd edition) . Dit artikel geeft een samenvatting weer van de essentie van deze architecturele opdeling van een applicatie.   Ontwerp principes Hanteer bij het ontwerpen van een applicatie de volgende vijf principes: Scheiden van verantwoordelijkheid (Separation of concerns) . Deel de toepassing op in afzonderlijke functies met zo min mogelijk overlap. Afzonderlijke verantwoordelijkheid (Single Responsibility) principe . Elke component- of module moet verantwoordelijk zijn voor een bepaalde functie / functionaliteit of over de samenvoeging van samenhangende functionaliteit. Het principe van minste kennis (Principle of Least Knowledge) . Een component of een obj...
Een reactie posten
Meer lezen