Implementatieaanpakfilosofieën
Watervalbenadering
De watervalbenadering voor het implementeren van een applicatie vereist dat een ontwerper overlegt met een of meer vertegenwoordigers van de eindgebruikersorganisatie en alle applicatiespecificaties opschrijft. Specificaties worden doorgaans geleverd in een reeks functionele documenten of gebruiksscenario's, die zo zijn geschreven dat de eindgebruiker de documenten gemakkelijk kan lezen en begrijpen.
De eindgebruiker ondertekent deze documenten en de documenten worden vervolgens verzameld door het technische ontwerpteam dat de applicatie ontwerpt, waarbij verschillende artefacten worden gecreëerd, zoals klassemodeldiagrammen, statusdiagrammen, activiteitendiagrammen en datamodellen. Het doel van deze fase is om alles zo gedetailleerd te schrijven dat een ontwikkelaar er geen probleem mee heeft om de benodigde code te maken. Er vindt een formele overdracht van het ontwerp plaats aan het ontwikkelteam en het testteam. Na oplevering begint het ontwikkelteam met coderen en gebruikt het testteam het technische ontwerp in combinatie met use cases om testcases en testscenario’s te creëren.
Nadat het ontwikkelteam klaar is met coderen, wordt de code overgedragen aan het testteam. Het testteam voert de door haar ontworpen tests uit op basis van de eisen en het detailontwerp. Eventuele problemen worden opgelost door het ontwikkelteam. Nadat het test- en herstelproces is voltooid, wordt de applicatie overgedragen aan de eindgebruiker voor acceptatietesten. De eindgebruiker voert een laatste controle uit om te zien of de applicatie aan de initiële eisen voldoet. Indien goedgekeurd, keurt hij het eindproduct goed en is het project voltooid. Nadat het ontwikkelteam klaar is met coderen, wordt de code overgedragen aan het testteam.
Het testteam voert de door haar ontworpen tests uit op basis van de eisen en het detailontwerp. Eventuele problemen worden opgelost door het ontwikkelteam. Nadat het test- en herstelproces is voltooid, wordt de applicatie overgedragen aan de eindgebruiker voor acceptatietesten. De eindgebruiker voert een laatste controle uit om te zien of de applicatie aan de initiële eisen voldoet. Indien goedgekeurd, keurt hij het eindproduct goed en is het project voltooid. Nadat het ontwikkelteam klaar is met coderen, wordt de code overgedragen aan het testteam. Het testteam voert de door haar ontworpen tests uit op basis van de eisen en het detailontwerp.
Eventuele problemen worden opgelost door het ontwikkelteam. Nadat het test- en herstelproces is voltooid, wordt de applicatie overgedragen aan de eindgebruiker voor acceptatietesten. De eindgebruiker voert een laatste controle uit om te zien of de applicatie aan de initiële eisen voldoet. Indien goedgekeurd, keurt hij het eindproduct goed en is het project voltooid.
De eindgebruiker voert een laatste controle uit om te zien of de applicatie aan de initiële eisen voldoet. Indien goedgekeurd, keurt hij het eindproduct goed en is het project voltooid. De eindgebruiker voert een laatste controle uit om te zien of de applicatie aan de initiële eisen voldoet. Indien goedgekeurd, keurt hij het eindproduct goed en is het project voltooid.
Bij gebruik van de watervalbenadering kan een project meer of minder fasen hebben, maar het belangrijkste kenmerk is een zeer formeel begin en einde van elke fase, met zeer formele resultaten.
Het voordeel van de watervalaanpak is dat de verantwoordelijkheid van het team dat verantwoordelijk is voor elke fase groter is. Het is duidelijk wat ze moeten leveren, wanneer ze dat moeten doen en aan wie ze dat moeten doen. Vaak hoeft het ontwikkelteam geen interactie met de gebruiker te hebben. Dit kan erg handig zijn als u de ontwikkeling naar een ander land uitbesteedt.
Het grootste nadeel van de watervalbenadering is dat in een omgeving waar alles op een zeer formele manier is georganiseerd, de flexibiliteit om op veranderingen te reageren afneemt. Zelfs verhuizen moet georganiseerd worden. Zeer weinig bedrijven lijken dit effectief te doen, wat vaak resulteert in een aanzienlijke stijging van de overheadkosten. Om de kosten van een project te beheersen, stellen sommige bedrijven eventuele wijzigingen in de vereisten zelfs uit tot de eerste oplevering van de applicatie, waardoor ze feitelijk een applicatie opleveren die niet voldoet aan de behoeften van de eindgebruiker.
Soepele ontwikkeling
Veel langlopende softwareontwikkelingsprojecten hebben het budget overschreden en zijn er niet in geslaagd het product op tijd op te leveren. Het uitgangspunt van de agile softwareontwikkelingsfilosofie is het minimaliseren van risico's door software te ontwikkelen in korte tijdsperioden, iteraties genoemd, die doorgaans één tot vier weken duren. Elke iteratie is als een eigen miniatuursoftwareproject en omvat alle taken die nodig zijn om de nieuwe functionaliteitsstap vrij te geven: planning, analyse van de vereisten, ontwerp, codering, testen en documentatie. Hoewel een iteratie misschien niet genoeg functionaliteit toevoegt om de release van een product te rechtvaardigen, streeft een agile softwareproject ernaar om aan het einde van elke iteratie nieuwe software te kunnen vrijgeven. Aan het einde van elke iteratie evalueert het team de projectprioriteiten opnieuw.
Het doel van agile softwareontwikkeling is het bereiken van klanttevredenheid door snelle en continue levering van bruikbare software; altijd gericht op het bouwen van wat de klant nodig heeft; late wijzigingen in de vereisten verwelkomen in plaats van ertegen te zijn; zich regelmatig aanpassen aan veranderende omstandigheden; hebben een nauwe, dagelijkse samenwerking tussen ondernemers en ontwikkelaars, waarbij face-to-face gesprek de beste vorm van communicatie is.
Het belangrijkste voordeel van agile softwareontwikkeling is de flexibiliteit bij het omgaan met veranderingen, waarbij er altijd naar wordt gestreefd om te voldoen aan de zakelijke behoeften. Het nadeel is natuurlijk dat de complexiteit van het beheren van de scope, planning en budgettering toeneemt. Een ander veelvoorkomend risico is de beperkte aandacht voor (technische) documentatie.
Incrementele ontwikkeling
Incrementele softwareontwikkeling is een mix van agile- en watervalontwikkeling. Een applicatie wordt stapsgewijs ontworpen, geïmplementeerd en getest, zodat elke stap aan de eindgebruiker kan worden geleverd. Het project is pas voltooid als de laatste stap is voltooid. Het heeft tot doel de waterval te verkorten door tussenstappen te definiëren en enkele voordelen van agile ontwikkeling te benutten. Op basis van de ontvangen feedback over een eerdere stap kunnen aanpassingen worden doorgevoerd bij het leveren van de volgende stap. De volgende stap kan bestaan uit nieuwe code, maar ook uit aanpassingen aan eerder verstrekte code.
Het voordeel is dat de formaliteiten blijven bestaan, maar het verandermanagement eenvoudiger wordt. De kosten voor het meerdere keren testen en implementeren van een applicatie zullen hoger zijn dan wanneer u dit slechts één keer doet.
Programmastroomcontrole
Het kiezen van een aanpak voor programmastroomcontrole is een zeer architecturale taak. Het doel is om een blauwdruk van uw applicatie te maken waarin, zodra u functionaliteit en code gaat toevoegen, alles een eigen plek lijkt te hebben. Als u ooit code van hoge kwaliteit heeft beoordeeld of geschreven, begrijpt u dit principe
Organiserende code
De eerste stap bij het ontwerpen van de programmastroom is het organiseren van de code, waarbij een reeks regels wordt vastgesteld om te helpen bij het maken van een plan of overzicht van de toepassing. Onderhoud, foutopsporing en probleemoplossing zullen gemakkelijker plaatsvinden omdat de code zich op één logische locatie bevindt. Nadat u de basis hebt gelegd, kunt u een aanpak kiezen voor het implementeren van uw applicatielogica.
Ontwerppatronen zouden een belangrijke rol moeten spelen bij het ontwerp van programmastroomcontrole. Door de jaren heen is er veel code geschreven en zijn er veel oplossingen ontworpen voor terugkerende problemen. Deze oplossingen worden vastgelegd in ontwerppatronen. Door een ontwerppatroon toe te passen op een veelvoorkomend softwareontwerpprobleem, kunt u oplossingen creëren die gemakkelijk herkenbaar zijn en door uw collega's kunnen worden geïmplementeerd. Unieke problemen vereisen nog steeds unieke oplossingen, maar u kunt ontwerppatronen gebruiken om u te begeleiden bij het oplossen ervan.
Het project maken
Lagen
De eerste stap is het overwegen van de logische lagen. Merk op dat lagen niet hetzelfde zijn als lagen, vaak verward of zelfs als hetzelfde worden beschouwd.
Lagen versus lagen
Lagen gaan over het creëren van grenzen in uw code. De bovenste laag kan verwijzingen hebben naar code in lagere lagen, maar een laag kan nooit een verwijzing hebben naar code in een hogere laag. Gelaagdheid betreft de fysieke verdeling van lagen over meerdere computers. In een applicatie met drie lagen is de gebruikersinterface bijvoorbeeld ontworpen om op een desktopcomputer te draaien, is de applicatielogica ontworpen om op een applicatieserver te draaien en draait de database op een databaseserver. elke laag kan uit meerdere lagen bestaan.
Figuur 8-1: Basisorganisatie met drie lagen
Lagen verwijzen naar abstractieniveaus. De lagen in Figuur 8.1 gelden voor de meeste toepassingen. Deze niveaus worden ook wel de drie hoofdlagen genoemd en kunnen verschillende andere namen hebben. In de regel kan code in de presentatielaag services in de logische applicatielaag aanroepen, maar mag de logische applicatielaag de methode in de presentatielaag niet aanroepen. De presentatielaag mag nooit rechtstreeks de gegevenstoegangslaag aanroepen, omdat dit de verantwoordelijkheden zou omzeilen die door de applicatielogicalaag zijn geïmplementeerd. De gegevenstoegangslaag mag nooit de logische applicatielaag aanroepen.
Lagen zijn slechts een abstractie en waarschijnlijk is de eenvoudigste manier om lagen te implementeren het maken van mappen in uw project en het toevoegen van code aan de juiste map. Een nuttiger aanpak zou zijn om elke laag in een afzonderlijk project te plaatsen, waardoor afzonderlijke samenstellingen ontstaan. Het voordeel van het plaatsen van uw applicatielogica in een bibliotheekassemblage is dat u unit-tests kunt maken met behulp van Microsoft Visual Studio of NUnit, om de logica te testen. Het creëert ook flexibiliteit bij het kiezen waar elke laag moet worden ingezet.
Fysieke lagen
In een bedrijfstoepassing moet u verwachten dat u meerdere clients voor dezelfde logica heeft. Wat een applicatie tot een bedrijfsapplicatie maakt, is dat deze in drie lagen wordt ingezet: client, applicatieserver en databaseserver. De Microsoft Office Access-applicatie die door de verkoopafdeling van uw bedrijf is gemaakt, is weliswaar erg belangrijk voor de verkoopafdeling, maar is geen bedrijfstoepassing.
Houd er rekening mee dat de applicatielogica en de gegevenstoegangslagen vaak samen op de applicatieserver worden geïmplementeerd. Onderdeel van het ontwerpen van het project is de keuze of u toegang wilt krijgen tot de applicatieserver via .NET of externe webservices. Ongeacht uw keuze voegt u wat code toe om eenvoudig toegang te krijgen tot de externe services in de presentatielaag. Als u Web Services gebruikt om toegang te krijgen tot services op uw toepassingsserver, doet Visual Studio .NET het werk voor u en genereert de proxycode, waardoor automatisch een implementatie van het externe proxypatroon wordt geleverd.
Patronen aan lagen toevoegen
De drie basislagen bieden een overzicht op hoog niveau. Laten we enkele structurele patronen toevoegen om een robuuste bedrijfsarchitectuur te creëren. Het resultaat wordt weergegeven in figuur 8-2.
Focus op de applicatielogicalaag. Figuur 8-2 laat zien dat toegang tot de applicatielogica gebruik maakt van het gevelpatroon. Een façade is een object dat een vereenvoudigde interface biedt voor een groter geheel aan code, zoals een klassenbibliotheek. Een façade kan de externe codeafhankelijkheid van de interne werking van een bibliotheek verminderen, omdat de meeste code de façade gebruikt, waardoor meer flexibiliteit bij de systeemontwikkeling mogelijk wordt. Om dit te doen zal de gevel een grofkorrelige interface vormen met een verzameling fijnkorrelige objecten.
Beslissingsstroom
Programmastroomcontrole, ook wel beslissingsstroom genoemd, heeft betrekking op de manier waarop u de services in de logische laag van uw applicatie ontwerpt of, zoals u in de vorige paragraaf hebt gezien, hoe u de methoden in uw gevel ontwerpt.
Er zijn twee manieren om uw diensten te organiseren:
- Actie georienteerd
- Staatsgericht
Actiegerichte aanpak
Door services te organiseren op basis van gebruikersacties, implementeer je applicatielogica door services aan te bieden, die elk een specifiek verzoek uit de presentatielaag afhandelen. Dit wordt ook wel het transactiescriptpatroon genoemd. Deze aanpak is populair omdat het eenvoudig is en heel natuurlijk aanvoelt. Voorbeelden van methoden die deze aanpak volgen zijn BookStoreService.AddNewOrder(Order order) en BookStoreService.CancelOrder(int orderId).
De logica die nodig is om de actie uit te voeren, wordt zeer sequentieel binnen de methode geïmplementeerd, waardoor het zeer leesbaar maar ook moeilijker wordt om de code opnieuw te gebruiken. Het gebruik van aanvullende ontwerppatronen, zoals het tabelmodulepatroon, kan de herbruikbaarheid helpen vergroten.
Staatsgerichte aanpak
Het is ook mogelijk om de beslissingsstroom van de applicatie veel meer toestandsgericht te implementeren. De diensten die door de applicatieserver worden aangeboden zijn meer generiek van aard, bijvoorbeeld BookStoreService.SaveOrder(Bestelvolgorde). Bij deze methode wordt gekeken naar de bestelstatus en wordt besloten of een nieuwe bestelling wordt toegevoegd of een bestaande bestelling wordt geannuleerd.
Datastructuurprojecten
Bij het ontwerpen van uw datastructuren moet u verschillende keuzes maken. De eerste keuze is het mechanisme voor gegevensopslag, de tweede is het beoogde gebruik van de gegevens en de derde is de versievereisten. Er zijn drie manieren om naar datastructuurontwerpen te kijken:
- Diensten bieden gegevens aan; gegevens zijn een weerspiegeling van de relationele database.
- Gegevens moeten worden toegewezen aan objecten en services bieden toegang tot objecten.
- De gegevens die door diensten worden aangeboden, moeten schemagebaseerd zijn.
Het kiezen van een van de drie als basis voor uw datastroomstructuur moet in een vroeg stadium van het ontwerpproces worden gemaakt. Veel bedrijven hebben een bedrijfsbeleid dat een van de drie opties voor alle projecten verplicht stelt, maar indien mogelijk moet u de opties voor elk project opnieuw evalueren en de ideale aanpak voor het betreffende project kiezen.
Een dataopslag-engine kiezen
Bij het ontwerpen van uw applicatie zult u ongetwijfeld een vorm van gegevensopslag moeten ontwerpen. De volgende winkels en vormen van gegevensopslag zijn beschikbaar:
- Dossier
- app.config-bestand
- XML-bestanden
- platte tekstbestanden
- Databank
- Berichtenwachtrij
Elke winkel heeft zijn eigen unieke kenmerken en kan worden afgestemd op specifieke wensen.
Het ontwerpen van de datastroom
Gegevensstroom met behulp van ADO.NET
Bij het implementeren van datacentrische services in de applicatielogicalaag ontwerpt u uw datastroom met behulp van ADO.NET. De .NET Framework-klassebibliotheek biedt een uitgebreide application programming interface (API) voor het manipuleren van gegevens in beheerde code. De API, ook wel ADO.NET genoemd, is te vinden in de naamruimte System.Data. De volledige scheiding van media- en datastores is een belangrijk ontwerpkenmerk van ADO.NET. Klassen als DataSet, DataTable en DataRow zijn ontworpen om gegevens op te slaan, maar behouden geen enkele kennis van waar de gegevens vandaan komen. Ze worden beschouwd als gegevensbron-agnostisch. Een aparte set klassen, zoals SqlConnection, SqlDataAdapter en SqlCommand, zorgen voor de verbinding met een gegevensbron, het ophalen van gegevens en het vullen van de DataSet, DataTable en DataRow. Deze klassen bevinden zich in subnaamruimten zoals System.Data.Sql, System.Data.OleDB, System.Data.Oracle, enzovoort. Afhankelijk van met welke databron je verbinding wilt maken, kun je klassen in de juiste naamruimte gebruiken, en afhankelijk van de omvang van het product dat je gebruikt, zul je merken dat deze klassen meer of minder functionaliteit bieden.
Omdat de DataSet niet is verbonden met de gegevensbron, kan deze met succes worden gebruikt om de gegevensstroom in een applicatie te beheren. Figuur 8.5 toont de gegevensstroom wanneer u dit doet.
Laten we dit project eens bekijken en ons voorstellen dat iemand zich heeft aangemeld bij uw boekwinkel en drie boeken heeft besteld. De presentatielaag beheerde de status van het winkelwagentje. De klant is klaar om de bestelling te plaatsen en heeft alle benodigde gegevens verstrekt. Hij kiest ervoor om de bestelling te verzenden. De webpagina transformeert alle gegevens in een DataSet die twee DataTables bevat, één voor bestelling en één voor bestelling; voegt een DataRow in voor het verzoek; en voegt drie DataRows in voor de orderregels. De webpagina geeft deze gegevens vervolgens opnieuw weer aan de gebruiker, controleert de gegevensbinding met de DataSet en vraagt Weet u het zeker? De gebruiker bevestigt het verzoek en het wordt ingediend bij de logische laag van de applicatie. De applicatielogicalaag controleert de DataSet om te zien of alle verplichte velden een waarde hebben en voert een controle uit om te zien of de gebruiker meer dan US$ 1.000 heeft. 00,- op openstaande rekeningen. Als alles in orde is, wordt de DataSet doorgegeven aan de datatoegangslaag, die verbinding maakt met de database en invoeginstructies genereert op basis van de DataSet-informatie.
Het op deze manier gebruiken van de DataSet is een snelle en efficiënte manier om een applicatie te maken en de kracht van de Framework Class Library en de mogelijkheid van ASP.NET te gebruiken om gegevens aan meerdere besturingselementen te binden, zoals de GridView tegen een DataSet. In plaats van eenvoudige DataSet-objecten te gebruiken, kunt u Typed DataSet-objecten gebruiken en de codeerervaring verbeteren door code in de presentatielaag en in de applicatielogicalaag te implementeren. Het voordeel van deze aanpak is tegelijkertijd het nadeel van de aanpak. Kleine veranderingen in het datamodel leiden er niet noodzakelijkerwijs toe dat veel methoden hun handtekening moeten veranderen. Qua onderhoud werkt dit dus heel goed. Als u zich herinnert dat de presentatielaag niet noodzakelijkerwijs een gebruikersinterface is, kan deze ook een webservice zijn. En als u de DataSet-definitie wijzigt, misschien omdat u de naam van een veld in de database wijzigt, dan wijzigt u het contract dat de Zoals u zich kunt voorstellen, kan dit tot enkele aanzienlijke problemen leiden. Dit scenario werkt goed als de presentatielaag slechts een gebruikersinterface is, maar voor interfaces met externe systemen of componenten wilt u de interne werking van uw applicatie verbergen en gegevens transformeren in iets anders dan een directe kloon van uw datamodel en u wilt Data Transfer Objects (DTO's) maken.
Gegevensstroom met behulp van objectrelationele mapping
Gegevensstroom met behulp van ADO.NET is een zeer datagerichte benadering voor het beheren van de gegevensstroom. Gegevens en logica zijn discreet. De andere kant van het spectrum kiest voor een meer objectgeoriënteerde benadering. Hier worden klassen gemaakt om gegevens en gedrag te groeperen. Het doel is om klassen te definiëren die de gegevens en het gedrag nabootsen die voorkomen in het bedrijfsdomein waarvoor de applicatie is gemaakt. Het resultaat wordt vaak een bedrijfsobject genoemd. De verzameling bedrijfsobjecten waaruit de applicatie bestaat, wordt het domeinmodel genoemd. Sommige ontwikkelaars beweren dat een rijk domeinmodel beter is voor het ontwerpen van complexere logica. Het is moeilijk om een dergelijke bewering te bewijzen of te weerleggen. Weet gewoon dat je een keuze hebt en dat het aan jou is om die te maken.
Figuur 8.6 toont een gegevensstroom vergelijkbaar met Figuur 8.5, behalve dat je nu de object-relationele mappinglaag hebt toegevoegd en de DataSet-objecten hebt vervangen door andere gegevensdragers.
Doe nu stap voor stap hetzelfde als voorheen; Stel je voor dat iemand inlogt op jouw boekwinkel en drie boeken bestelt. De presentatielaag beheerde de status van het winkelwagentje. De klant is klaar om de bestelling te plaatsen en heeft alle benodigde gegevens verstrekt. Hij kiest ervoor om de bestelling te verzenden. De webpagina transformeert alle gegevens in een DTO, met gegevens voor één order en met drie orderregels, waarbij de objecten naar behoefte worden gemaakt. De webpagina geeft deze gegevens nogmaals weer aan de gebruiker, gegevensbindende controles tegen de DTO met behulp van de ObjectDataSource in ASP.NET 2.0, en vraagt Weet u het zeker? De gebruiker bevestigt de keuze en de DTO wordt ingediend bij de logische laag van de applicatie. De applicatielogicalaag transformeert de DTO in een bedrijfsobject van het type Order met de eigenschap om drie OrderLine-objecten te bevatten. De bestelmethode. Validate() wordt aangeroepen om de bestelling te valideren en te controleren of alle verplichte velden een waarde hebben, en er wordt gecontroleerd of de gebruiker meer dan R$ 1.000,00 aan openstaande facturen heeft. Om dit te doen, zal de bestelling Order.Customer.GetOutstandingBills() aanroepen. Als alles in orde is, wordt de methode Order.Save() aangeroepen. De order wordt ingediend bij de objectrelationele mappinglaag, waar de order en orderregels worden toegewezen aan een DataTable in een DataSet, en de DataSet wordt doorgegeven aan de datatoegangslaag, die verbinding maakt met de database en invoeginstructies genereert op basis van de informatie in de DataSet. Er zijn uiteraard veel manieren waarop object-relationele mapping kan plaatsvinden, maar deze omvatten niet allemaal transformatie naar een DataSet. Sommigen zullen de insert-instructies rechtstreeks maken, maar zullen nog steeds de datatoegangslaag gebruiken om die instructie uit te voeren.
Zoals je kunt zien, vinden er enkele transformaties plaats. De inzet van DTO’s is nodig omdat een bedrijfsobject gedrag implementeert en gedrag aan verandering onderhevig is. Om de impact van deze wijzigingen op de presentatielaag te minimaliseren, moet u de gegevens uit het bedrijfsobject transformeren naar een gegevensoverdrachtobject. In Java wordt het gegevensoverdrachtobject doorgaans een waardeobject genoemd.
Een groot voordeel van het werken met bedrijfsobjecten is dat het je code echt helpt organiseren. Als je terugkijkt op een stukje complexe logica, is het meestal heel leesbaar omdat er heel weinig loodgieterscode is. Het nadeel is dat de meeste datastores nog steeds relationeel zijn en dat het in kaart brengen van bedrijfsobjecten aan relationele data behoorlijk complex kan worden.
Schemagebaseerde diensten
U hebt zojuist twee tegenpolen gezien als het gaat om het beheren van de gegevensstroom. Er zijn veel variaties mogelijk. Een veel voorkomende variant is de variant waarbij een dataset wordt gebruikt als basisgegevensondersteuning voor de gebruikersinterface voor gegevensopslag, maar afzonderlijke schema's (DTO's) worden gebruikt voor webservices die vanuit andere systemen worden aangeroepen. De applicatielaag transformeert relationele gegevens in een vooraf gedefinieerd schema. Het belangrijkste voordeel hiervan is dat elke applicatie die naar de service verwijst, niet afhankelijk is van enige vorm van interne implementatie van de component. Dit zorgt voor meer flexibiliteit bij het versiebeheer, achterwaartse compatibiliteit van interfaces en de mogelijkheid om de implementatie van componenten te wijzigen zonder de service-interface te wijzigen.
Natuurlijk kunt u bedrijfsobjecten in de webapplicatie gebruiken en de DTO-transformatie omzeilen, maar dit werkt over het algemeen alleen goed als de applicatielogica samen met de webapplicatie wordt geïmplementeerd. Houd er rekening mee dat u voor het aanroepen van Order.Save() een databaseverbinding. Of dit wenselijk is, is aan u en waarschijnlijk uw beveiligingsdirecteur.