Ik heb echt behoefte aan een eerlijk, doordacht debat over de verdiensten van het momenteel geaccepteerde enterprise-applicatie-ontwerpparadigma.
Ik ben er niet van overtuigd dat entiteitsobjecten zouden moeten bestaan.
Met entiteitsobjecten bedoel ik de typische dingen die we meestal voor onze applicaties bouwen, zoals “Persoon”, “Account”, “Order”, enz.
Mijn huidige ontwerpfilosofie is deze:
- Alle toegang tot de database moet worden bereikt via opgeslagen procedures.
- Als u gegevens nodig heeft, roept u een opgeslagen procedure aan en herhaalt u een SqlDataReader of de rijen in een DataTable
(Opmerking: ik heb ook bedrijfsapplicaties gebouwd met Java EE, Java-mensen, vervang alstublieft het equivalent voor mijn .NET-voorbeelden)
Ik ben niet anti-OO. Ik schrijf veel lessen voor verschillende doeleinden, alleen niet voor entiteiten. Ik geef toe dat een groot deel van de lessen die ik schrijf statische hulplessen zijn.
Ik ben geen speelgoed aan het bouwen. Ik heb het over grote, hoogvolume transactionele applicaties die op meerdere machines worden ingezet. Webapplicaties, windows-services, webservices, b2b-interactie, noem maar op.
Ik heb OR Mappers gebruikt. Ik heb er een paar geschreven. Ik heb de Java EE-stack, CSLA en een paar andere equivalenten gebruikt. Ik heb ze niet alleen gebruikt, maar deze applicaties ook actief ontwikkeld en onderhouden in productieomgevingen.
Ik ben tot de beproefde conclusie gekomen dat entiteitsobjecten ons in de weg zitten en dat ons leven zoveel gemakkelijker zou zijn zonder hen.
Beschouw dit eenvoudige voorbeeld: u krijgt een ondersteuningsoproep over een bepaalde pagina in uw toepassing die niet correct werkt, misschien wordt een van de velden niet bewaard zoals zou moeten. Bij mijn model opent de ontwikkelaar die is toegewezen om het probleem te vinden exact 3 bestanden. Een ASPX, een ASPX.CS en een SQL-bestand met de opgeslagen procedure. Het probleem, dat mogelijk een ontbrekende parameter is voor de aanroep van de opgeslagen procedure, duurt minuten om op te lossen. Maar met elk entiteitsmodel start u steevast de debugger, begint u door de code te stappen en kunt u eindigen met 15-20 bestanden geopend in Visual Studio. Tegen de tijd dat je naar de onderkant van de stapel stapt, ben je vergeten waar je bent begonnen. We kunnen maar zoveel dingen tegelijk in ons hoofd hebben. Software is ongelooflijk complex zonder onnodige lagen toe te voegen.
Ontwikkelcomplexiteit en probleemoplossing zijn slechts één kant van mijn probleem.
Laten we het nu hebben over schaalbaarheid.
Beseffen ontwikkelaars dat elke keer dat ze code schrijven of wijzigen die interactie heeft met de database, ze een grondige analyse moeten maken van de exacte impact op de database? En niet alleen de ontwikkelingskopie, ik bedoel een nabootsing van productie, dus u kunt zien dat de extra kolom die u nu voor uw object nodig heeft, het huidige queryplan ongeldig heeft gemaakt en een rapport dat in 1 seconde werd uitgevoerd, duurt nu 2 minuten, slechts omdat u een enkele kolom aan de selectielijst hebt toegevoegd? En het blijkt dat de index die u nu nodig heeft zo groot is dat de DBA de fysieke lay-out van uw bestanden zal moeten wijzigen?
Als je mensen met een abstractie te ver weg laat gaan van de fysieke gegevensopslag, zullen ze een ravage aanrichten met een applicatie die moet worden geschaald.
Ik ben geen ijveraar. Ik kan ervan overtuigd zijn als ik het mis heb, en misschien ben ik dat ook, aangezien er zo’n sterke druk is in de richting van Linq naar Sql, ADO.NET EF, Hibernate, Java EE, enz. Denk goed na over uw antwoorden, als ik iets mis ik wil echt weten wat het is en waarom ik van gedachten moet veranderen.
[Bewerken]
Het lijkt erop dat deze vraag plotseling weer actief is, dus nu we de nieuwe commentaarfunctie hebben, heb ik direct op verschillende antwoorden gereageerd. Bedankt voor de reacties, ik denk dat dit een gezonde discussie is.
Ik had waarschijnlijk duidelijker moeten zijn dat ik het over bedrijfsapplicaties heb. Ik kan echt geen commentaar geven op bijvoorbeeld een game die op iemands desktop of een mobiele app draait.
Eén ding moet ik hier bovenaan plaatsen als reactie op verschillende vergelijkbare antwoorden: orthogonaliteit en scheiding van zorgen worden vaak aangehaald als redenen om entiteit/ORM te gaan gebruiken. Opgeslagen procedures zijn voor mij het beste voorbeeld van scheiding van zorgen dat ik kan bedenken. Als u alle andere toegang tot de database verbiedt, behalve via opgeslagen procedures, zou u in theorie uw hele gegevensmodel opnieuw kunnen ontwerpen en geen code kunnen breken, zolang u de invoer en uitvoer van de opgeslagen procedures handhaaft. Ze zijn een perfect voorbeeld van programmeren op contract (zolang u “selecteer *” maar vermijdt en de resultatensets documenteert).
Vraag iemand die al heel lang in de branche zit en met langlevende applicaties heeft gewerkt: hoeveel applicatie- en UI-lagen zijn er gekomen en gegaan terwijl een database voortleeft? Hoe moeilijk is het om een database af te stemmen en te refactoren als er 4 of 5 verschillende persistentielagen zijn die SQL genereren om bij de gegevens te komen? Je kunt niets veranderen! ORM’s of andere code die SQL genereert vergrendel uw database in steen.
Antwoord 1, autoriteit 100%
Ik denk dat het neerkomt op hoe ingewikkeld de “logica” van de applicatie is en waar je deze hebt geïmplementeerd. Als al uw logica in opgeslagen procedures zit en uw toepassing alleen die procedures aanroept en de resultaten weergeeft, dan is het ontwikkelen van entiteitsobjecten inderdaad tijdverspilling. Maar voor een toepassing waar de objecten een rijke interactie met elkaar hebben en de database slechts een persistentiemechanisme is, kan het waardevol zijn om die objecten te hebben.
Dus ik zou zeggen dat er geen pasklaar antwoord is. Ontwikkelaars moeten zich ervan bewust zijn dat soms proberen te OO te zijn, meer problemen kan veroorzaken dan het oplost.
Antwoord 2, autoriteit 46%
De theorie zegt dat zeer samenhangende, losjes gekoppelde implementaties de weg vooruit zijn.
Dus ik neem aan dat je die benadering in twijfel trekt, namelijk het scheiden van zorgen.
Moet mijn aspx.cs-bestand interactie hebben met de database, een sproc aanroepen en IDataReader begrijpen?
In een teamomgeving, vooral waar minder technische mensen zich bezighouden met het aspx-gedeelte van de applicatie, heb ik niet nodig dat deze mensen deze dingen kunnen “aanraken”.
Het scheiden van mijn domein van mijn database beschermt me tegen structurele veranderingen in de database, toch een goede zaak? De effectiviteit van de database is absoluut belangrijk, dus laat iemand die daar het beste in is, die dingen op één plek afhandelen, met zo min mogelijk impact op de rest van het systeem.
Tenzij ik uw aanpak verkeerd begrijp, kan één structurele verandering in de database een groot effect hebben op het oppervlak van uw toepassing. Ik zie dat deze scheiding van zorgen mij en mijn team in staat stelt dit tot een minimum te beperken. Ook zou elk nieuw lid van het team deze aanpak beter moeten begrijpen.
Ook lijkt uw benadering te pleiten voor de bedrijfslogica van uw toepassing om in uw database te verblijven? Dit voelt verkeerd voor mij, SQL is echt goed in het opvragen van gegevens, en niet, imho, het uitdrukken van bedrijfslogica.
Interessante gedachte echter, hoewel het een stap verwijderd voelt van SQL in de aspx, wat me uit mijn slechte, oude, ongestructureerde asp-dagen vervult met angst.
Antwoord 3, autoriteit 44%
Eén reden – het scheiden van uw domeinmodel van uw databasemodel.
Wat ik doe is testgestuurde ontwikkeling gebruiken, dus ik schrijf eerst mijn UI- en modellagen en de gegevenslaag wordt bespot, dus de gebruikersinterface en het model zijn gebouwd rond domeinspecifieke objecten, en later wijs ik deze objecten toe aan welke technologie dan ook. gebruik de gegevenslaag. Het is een slecht idee om de databasestructuur het ontwerp van uw applicatie te laten bepalen. Schrijf waar mogelijk eerst de app en laat dat de structuur van je database beïnvloeden, niet andersom.
Antwoord 4, autoriteit 36%
Voor mij komt het erop neer dat ik niet wil dat mijn applicatie zich bezighoudt met hoe de gegevens worden opgeslagen. Ik zal waarschijnlijk een klap krijgen als ik dit zeg… maar je applicatie is niet je data, data is een artefact van de applicatie. Ik wil dat mijn applicatie denkt in termen van Klanten, Bestellingen en Artikelen, niet een technologie zoals DataSets, DataTables en DataRows… want wie weet hoe lang die er nog zullen zijn.
Ik ben het ermee eens dat er altijd een zekere mate van koppeling is, maar ik heb liever dat die koppeling naar boven reikt in plaats van naar beneden. Ik kan de ledematen en bladeren van een boom gemakkelijker aanpassen dan de stam.
Ik heb de neiging om sprocs te reserveren voor rapportage, omdat de zoekopdrachten de neiging hebben een beetje gemener te worden dan de algemene gegevenstoegang van de applicatie.
Ik heb ook de neiging om met de juiste unit-tests in een vroeg stadium te denken dat een kolom die niet wordt volgehouden, waarschijnlijk geen probleem is.
Antwoord 5, autoriteit 27%
Erik,
Je bent dood. Voor elke echt schaalbare / gemakkelijk te onderhouden / robuuste applicatie is het enige echte antwoord om af te zien van al het afval en vast te houden aan de basis.
Ik heb een soortgelijk traject gevolgd met mijn carrière en ben tot dezelfde conclusies gekomen. Natuurlijk worden we als ketters beschouwd en grappig bekeken. Maar mijn spullen werken en werken goed.
Elke regel code moet met argwaan worden bekeken.
Antwoord 6, autoriteit 17%
Ik zou graag willen antwoorden met een voorbeeld dat lijkt op het voorbeeld dat u heeft voorgesteld.
Voor mijn bedrijf moest ik een eenvoudige CRUD-sectie voor producten bouwen, ik bouwde al mijn entiteiten en een aparte DAL. Later moest een andere ontwikkelaar een gerelateerde tabel wijzigen en hij hernoemde zelfs verschillende velden. Het enige bestand dat ik moest wijzigen om mijn formulier bij te werken, was de DAL voor die tabel.
Wat (naar mijn mening) entiteiten aan een project toevoegen is:
Ortogonaliteit: wijzigingen in één laag hebben mogelijk geen invloed op andere lagen (natuurlijk, als u een enorme wijziging aanbrengt in de database, zou deze door alle lagen heen rimpelen, maar de meeste kleine wijzigingen niet).
Testbaarheid: u kunt uw logica testen zonder uw database aan te raken. Dit verhoogt de prestaties van uw tests (waardoor u ze vaker kunt uitvoeren).
Scheiding van zorgen: in een groot product kun je de database toewijzen aan een DBA en hij kan het helemaal optimaliseren. Wijs het model toe aan een bedrijfsexpert die over de nodige kennis beschikt om het te ontwerpen. Wijs individuele formulieren toe aan ontwikkelaars die meer ervaring hebben met webformulieren enz.
Tot slot zou ik willen toevoegen dat de meeste ORM-mappers opgeslagen procedures ondersteunen, aangezien u dat gebruikt.
Proost.
Antwoord 7, autoriteit 14%
Ik denk dat je “meer afbijt dan je kunt kauwen” over dit onderwerp. Ted Neward was niet luchthartig toen hij het de “Vietnam van computerwetenschappen“.
Eén ding dat ik je absoluut kan garanderen, is dat het niemands standpunt over deze kwestie zal veranderen, zoals zo vaak is bewezen op talloze andere blogs, forums, podcasts enz.
Het is zeker oké om openlijk te discussiëren en te debatteren over een controversieel onderwerp, het is alleen zo vaak gedaan dat beide ‘partijen’ het oneens waren en gewoon doorgingen met het schrijven van software.
Als je aan beide kanten wat meer wilt lezen, bekijk dan de artikelen op Ted’s blog, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans enz.
Antwoord 8, autoriteit 12%
@Dan, sorry, daar ben ik niet naar op zoek. Ik ken de theorie. Uw bewering “is een heel slecht idee” wordt niet ondersteund door een echt voorbeeld. We proberen software te ontwikkelen in minder tijd, met minder mensen, met minder fouten, en we willen de mogelijkheid hebben om gemakkelijk wijzigingen aan te brengen. Uw meerlagenmodel is naar mijn ervaring een minpunt in alle bovenstaande categorieën. Vooral met betrekking tot het datamodel het laatste wat je doet. Het fysieke datamodel moet vanaf dag 1 een belangrijke overweging zijn.
Antwoord 9, autoriteit 7%
Ik vond je vraag erg interessant.
Meestal heb ik entiteitsobjecten nodig om de bedrijfslogica van een applicatie in te kapselen. Het zou erg ingewikkeld en ontoereikend zijn om deze logica in de gegevenslaag te duwen.
Wat zou u doen om deze entiteitsobjecten te vermijden? Welke oplossing heb je in gedachten?
Antwoord 10, autoriteit 7%
Entiteitsobjecten kunnen cachen op de applicatielaag vergemakkelijken. Veel succes met het cachen van een datareader.
Antwoord 11, autoriteit 7%
We moeten ook praten over het idee wat entiteiten werkelijk zijn.
Als ik deze discussie doorlees, krijg ik de indruk dat de meeste mensen hier naar entiteiten kijken in de zin van een Anemisch domeinmodel.
Veel mensen beschouwen het Anemic Domain Model als een antipatroon!
Rijke domeinmodellen hebben waarde. Dat is waar het bij Domain Driven Designom draait.
Persoonlijk geloof ik dat OO een manier is om complexiteit te overwinnen. Dit betekent niet alleen technische complexiteit (zoals gegevenstoegang, ui-binding, beveiliging …) maar ook complexiteit in het zakelijke domein!
Als we OO-technieken kunnen toepassen om onze bedrijfsproblemen te analyseren, modelleren, en implementeren, is dit een enorm voordeel voor de onderhoudbaarheid en uitbreidbaarheid van niet-triviale applicaties!
Er zijn verschillen tussen uw entiteiten en uw tabellen. Entiteiten moeten uw model vertegenwoordigen, tabellen vertegenwoordigen alleen het data-aspect van uw model!
Het is waar dat gegevens langer meegaan dan apps, maar overweeg dit citaatvan David Laribee: Modellen zijn voor altijd … data is een gelukkig neveneffect.
Nog meer links over dit onderwerp:
Antwoord 12, autoriteit 7%
Echt interessante vraag. Eerlijk gezegd kan ik niet bewijzen waarom entiteiten goed zijn. Maar ik kan mijn mening delen waarom ik ze leuk vind. Code zoals
void exportOrder(Order order, String fileName){...};
maakt zich niet druk waar de bestelling vandaan kwam – van DB, van webverzoek, van unit-test, enz. Het maakt deze methode explicieter om aan te geven wat het precies vereist, in plaats van DataRow te nemen en te documenteren welke kolommen het verwacht te hebben en welke soorten die ze zouden moeten zijn. Hetzelfde is van toepassing als je het op de een of andere manier implementeert als een opgeslagen procedure – je moet er nog steeds een record-ID naar toe pushen, terwijl het niet noodzakelijk aanwezig zou moeten zijn in de DB.
Implementatie van deze methode zou worden gedaan op basis van orderabstractie, niet op basis van hoe deze precies in DB wordt gepresenteerd. De meeste van dergelijke bewerkingen die ik heb geïmplementeerd, zijn echt niet afhankelijk van hoe deze gegevens worden opgeslagen. Ik begrijp wel dat voor sommige bewerkingen een koppeling met de DB-structuur nodig is voor prestatie- en schaalbaarheidsdoeleinden, maar in mijn ervaring zijn er niet al te veel van. In mijn ervaring is het heel vaak voldoende om te weten dat Persoon .getFirstName() heeft die String retourneert en .getAddress() Adres retourneert, en adres heeft .getZipCode(), enz. – en het maakt niet uit welke tabellen betrokken zijn om die gegevens op te slaan .
Als je te maken krijgt met problemen zoals je hebt beschreven, zoals wanneer extra kolomonderbrekingen de prestaties rapporteren, dan is DB voor je taken een cruciaal onderdeel, en je zou er inderdaad zo dicht mogelijk bij moeten zijn. Hoewel entiteiten enkele handige abstracties kunnen bieden, kunnen ze ook enkele belangrijke details verbergen.
Schaalbaarheid is hier een interessant punt – de meeste websites die enorme schaalbaarheid vereisen (zoals facebook, livejournal, flickr) hebben de neiging om een DB-ascetische benadering te gebruiken, wanneer DB zo zeldzaam mogelijk wordt gebruikt en schaalbaarheidsproblemen worden opgelost door caching, vooral door RAM-gebruik. http://highscalability.com/heeft er een aantal interessante artikelen over.
Antwoord 13, autoriteit 7%
Er zijn andere goede redenen voor entiteitsobjecten naast abstractie en losse koppeling. Een van de dingen die ik het leukst vind, is het sterke typen dat je niet kunt krijgen met een DataReader of een DataTable. Een andere reden is dat als het goed wordt gedaan, de juiste entiteitsklassen de code beter onderhoudbaar kunnen maken door eersteklas constructies te gebruiken voor domeinspecifieke termen die iedereen die naar de code kijkt waarschijnlijk zal begrijpen in plaats van een reeks strings met veldnamen erin die worden gebruikt voor het indexeren van een DataRow. Opgeslagen procedures zijn echt orthogonaal voor het gebruik van een ORM, omdat veel mapping-frameworks je de mogelijkheid bieden om naar sprocs te mappen.
Ik zou sprocs + datareaders niet beschouwen als een vervanging voor een goede ORM. Met opgeslagen procedures bent u nog steeds beperkt door en nauw verbonden met de typehandtekening van de procedure, die een ander typesysteem gebruikt dan de aanroepende code. Opgeslagen procedures kunnen worden gewijzigd om extra opties en schemawijzigingen mogelijk te maken. Een alternatief voor opgeslagen procedures in het geval dat het schema aan verandering onderhevig is, is het gebruik van weergaven. U kunt objecten aan weergaven toewijzen en vervolgens weergaven opnieuw toewijzen aan de onderliggende tabellen wanneer u ze wijzigt.
Ik kan uw afkeer van ORM’s begrijpen als uw ervaring voornamelijk bestaat uit Java EE en CSLA. Je zou eens kunnen kijken naar LINQ to SQL, dat een zeer lichtgewicht raamwerk is en in de eerste plaats een één-op-één-toewijzing is met de databasetabellen, maar die meestal slechts een kleine uitbreiding nodig heeft om volwaardige bedrijfsobjecten te zijn. LINQ to SQL kan ook invoer- en uitvoerobjecten toewijzen aan parameters en resultaten van opgeslagen procedures.
Het ADO.NET Entity-framework heeft als bijkomend voordeel dat uw databasetabellen kunnen worden bekeken als entiteitsklassen die van elkaar overerven, of als kolommen uit meerdere tabellen die zijn samengevoegd tot één enkele entiteit. Als u het schema moet wijzigen, kunt u de toewijzing van het conceptuele model naar het opslagschema wijzigen zonder de daadwerkelijke toepassingscode te wijzigen. En nogmaals, hier kunnen opgeslagen procedures worden gebruikt.
Ik denk dat meer IT-projecten in ondernemingen mislukken vanwege onhoudbaarheid van de code of slechte productiviteit van ontwikkelaars (wat bijvoorbeeld kan gebeuren door contextwisseling tussen sproc-schrijven en app-schrijven) dan schaalbaarheidsproblemen van een applicatie.
p>
Antwoord 14, autoriteit 5%
Ik zou ook graag toevoegen aan Dan’s antwoorddat het scheiden beide modellen kunnen ervoor zorgen dat uw toepassing op verschillende databaseservers of zelfs op databasemodellen kan worden uitgevoerd.
Antwoord 15, autoriteit 5%
Wat als u uw app moet schalen door meer dan één webserver te verdelen? Je zou de volledige app op alle webservers kunnen installeren, maar een betere oplossing is om de webservers te laten praten met een applicatieserver.
Maar als er geen entiteitsobjecten zijn, hebben ze niet veel om over te praten.
Ik zeg niet dat je geen monolieten moet schrijven als het een eenvoudige, interne, korte levensduur is. Maar zodra het matig complex wordt, of een behoorlijke tijd mee moet gaan, moet je echt nadenken over een goed ontwerp.
Dit bespaart tijd bij het onderhoud.
Door toepassingslogica te splitsen van presentatielogica en gegevenstoegang, en door DTO’s ertussen door te geven, ontkoppelt u ze. Zodat ze onafhankelijk kunnen veranderen.
Antwoord 16, autoriteit 5%
Misschien vindt u ditbericht op comp.object interessant.
Ik beweer niet dat ik het ermee eens of oneens ben, maar het is interessant en (denk ik) relevant voor dit onderwerp.
Antwoord 17, autoriteit 5%
Een vraag: Hoe ga je om met losgekoppelde applicaties als al je bedrijfslogica vastzit in de database?
In het type Enterprise-applicatie waarin ik geïnteresseerd ben, hebben we te maken met meerdere sites, waarvan sommige moeten kunnen functioneren in een niet-verbonden staat.
Als uw bedrijfslogica is ingekapseld in een domeinlaag die eenvoudig in verschillende toepassingstypen kan worden opgenomen – bijvoorbeeld als een dll– dan kan ik toepassingen bouwen die op de hoogte zijn van de bedrijfsregels en die, wanneer nodig om ze lokaal toe te passen.
Om de domeinlaag in opgeslagen procedures in de database te houden, moet u zich houden aan één enkel type toepassing dat een permanente zichtlijn naar de database nodig heeft.
Het is oké voor een bepaalde klasse van omgevingen, maar het dekt zeker niet het hele spectrum van Enterprise-applicaties.
Antwoord 18, autoriteit 3%
@jdecuyper, een stelregel die ik vaak tegen mezelf herhaal, is “als uw bedrijfslogica niet in uw database staat, is het slechts een aanbeveling”. Ik denk dat Paul Nielson dat in een van zijn boeken zei. Applicatielagen en gebruikersinterface komen en gaan, maar gegevens blijven meestal heel lang bestaan.
Hoe vermijd ik entiteitsobjecten? Meestal opgeslagen procedures. Ik geef ook vrijelijk toe dat bedrijfslogica de neiging heeft om door alle lagen van een applicatie heen te reiken, of je het nu wilt of niet. Een zekere mate van koppeling is inherent en onvermijdelijk.
Antwoord 19, autoriteit 3%
Ik heb de laatste tijd veel over hetzelfde nagedacht; Ik was een tijdje een zware gebruiker van CSLA en ik hou van de puurheid om te zeggen dat “al je bedrijfslogica (of in ieder geval zoveel als redelijkerwijs mogelijk is) is ingekapseld in zakelijke entiteiten”.
Ik heb gezien dat het bedrijfsentiteitsmodel veel waarde biedt in gevallen waarin het ontwerp van de database anders is dan de manier waarop u met de gegevens werkt, wat het geval is in veel bedrijfssoftware.
Het idee van een ‘klant’ kan bijvoorbeeld bestaan uit een hoofdrecord in een tabel ‘Klanten’, gecombineerd met alle bestellingen die de klant heeft geplaatst, evenals alle medewerkers van de klant en hun contactgegevens, en sommige van de eigenschappen van een klant en zijn kinderen kunnen worden bepaald aan de hand van opzoektabellen. Vanuit het oogpunt van ontwikkeling is het heel fijn om als één entiteit met de klant te kunnen werken, aangezien vanuit een zakelijk perspectief het concept van de klant al deze dingen bevat en de relaties al dan niet worden afgedwongen in de database.
Hoewel ik het citaat waardeer dat “als uw bedrijfsregel niet in uw database staat, het slechts een suggestie is”, ben ik ook van mening dat u de database niet moet ontwerpen om bedrijfsregels af te dwingen, maar dat u deze moet ontwerpen om efficiënt te zijn, snel en genormaliseerd.
Dat gezegd hebbende, zoals anderen hierboven al hebben opgemerkt, is er geen “perfect ontwerp”, de tool moet bij de taak passen. Maar het gebruik van zakelijke entiteiten kan echt helpen bij onderhoud en productiviteit, aangezien u weet waar u heen moet om bedrijfslogica aan te passen en objecten op een intuïtieve manier realistische concepten kunnen modelleren.
Antwoord 20, autoriteit 3%
Eric,
Niemand houdt je tegen om het raamwerk/de aanpak te kiezen die je zou willen. Als je het pad “data-driven/stored procedure-powered” gaat, ga er dan zeker voor! Vooral als het je echt helpt om je applicaties op tijd en volgens specificaties te leveren.
Het voorbehoud (dat is een keerzijde van uw vraag) is dat AL uw bedrijfsregels op opgeslagen procedures moeten staan en dat uw toepassing niets meer is dan een thin client.
Dat gezegd hebbende, zijn dezelfde regels van toepassing als u uw toepassing in OOP doet: wees consistent. Volg de principes van OOP, en datomvat het maken van entiteitsobjecten om uw domeinmodellen weer te geven.
De enige echte regel hier is het woord consistentie. Niemand houdt je tegen om DB-centrisch te gaan werken. Niemand houdt je tegen om ouderwetse gestructureerde (oftewel functionele/procedurele) programma’s te doen. Verdorie, niemand houdt iemand tegen om code in COBOL-stijl te gebruiken. MAAR een applicatie moet heel, heel consistent zijn als het eenmaal dit pad is ingeslagen, als het enige mate van succes wil behalen.
Antwoord 21, autoriteit 3%
Ik weet echt niet wat je beschouwt als “Bedrijfsapplicaties”. Maar ik krijg de indruk dat u het definieert als een interne toepassing waarbij het RDBMS in steen gebeiteld zou worden en het systeem niet interoperabel zou hoeven zijn met andere systemen, zowel intern als extern.
Maar wat als u een database had met 100 tabellen die gelijk staan aan 4 Opgeslagen Procedures voor elke tabel, alleen voor basis CRUD-bewerkingen, dat zijn 400 opgeslagen procedures die moeten worden onderhouden en die niet sterk getypt zijn, dus gevoelig zijn voor typefouten en ook niet kunnen unit getest zijn. Wat gebeurt er als je een nieuwe CTO krijgt die een Open Source Evangelist is en het RDBMS wil veranderen van SQL Server naar MySql?
Veel software tegenwoordig, of het nu gaat om bedrijfsapplicaties of producten, die SOA gebruiken en bepaalde vereisten hebben voor het beschikbaar stellen van webservices, in ieder geval de software waarbij ik betrokken ben en ben geweest.
Als u uw aanpak gebruikt, zou u uiteindelijk een geserialiseerde datatabel of datarijen blootleggen. Nu kan dit als acceptabel worden beschouwd als de klant gegarandeerd .NET is en zich op een intern netwerk bevindt. Maar als de client niet bekend is, moet u ernaar streven een API te ontwerpen die intuïtief is en in de meeste gevallen wilt u niet het schema van de volledige database blootleggen.
Ik zou zeker niet aan een Java-ontwikkelaar willen uitleggen wat een DataTable is en hoe deze te gebruiken. Er is ook de overweging van bandbreedte en payload-grootte en geserialiseerde datatabellen, datasets zijn erg zwaar.
Er is geen wondermiddel met softwareontwerp en het hangt er echt van af waar de prioriteiten liggen, voor mij is het in Unit Testable-code en losjes gekoppelde componenten die gemakkelijk door elke klant kunnen worden gebruikt.
mijn 2 cent
Antwoord 22, autoriteit 3%
Ik wil graag een andere invalshoek bieden voor het probleem van de afstand tussen OO en RDB: geschiedenis.
Elke software heeft een model van de werkelijkheid dat tot op zekere hoogte een abstractie van de werkelijkheid is. Geen enkel computerprogramma kan alle complexiteiten van de werkelijkheid vastleggen, en programma’s zijn alleen geschreven om een reeks problemen vanuit de werkelijkheid op te lossen. Daarom is elk softwaremodel een reductie van de werkelijkheid. Soms dwingt het softwaremodel de werkelijkheid om zichzelf te verkleinen. Zoals wanneer u wilt dat het autoverhuurbedrijf een auto voor u reserveert zolang deze blauw is en legeringen heeft, maar de exploitant niet kan voldoen omdat uw verzoek niet in de computer past.
RDB komt voort uit een zeer oude traditie van het zetten van informatie in tabellen, de zogenaamde boekhouding. De boekhouding werd gedaan op papier, vervolgens op ponskaarten en vervolgens op computers. Maar boekhouden is al een verkleining van de werkelijkheid. Boekhouding heeft mensen gedwongen om zijn systeem zo lang te volgen dat het een geaccepteerde realiteit is geworden. Daarom is het relatief eenvoudig om computersoftware te maken voor de boekhouding, boekhouden heeft zijn informatiemodel al gehad, lang voordat de computer er was.
Gezien het belang van goede boekhoudsystemen en de acceptatie die u krijgt van alle bedrijfsmanagers, zijn deze systemen zeer geavanceerd geworden. De databasefundamenten zijn nu erg solide en niemand aarzelt om essentiële gegevens in zoiets betrouwbaars te bewaren.
Ik denk dat OO erbij moet zijn gekomen toen mensen ontdekten dat andere aspecten van de werkelijkheid moeilijker te modelleren zijn dan boekhouden (wat al een model is). OO is een zeer succesvol idee geworden, maar de persistentie van OO-gegevens is relatief onderontwikkeld. RDB/Accounting heeft gemakkelijke overwinningen behaald, maar OO is een veel groter veld (eigenlijk alles wat niet boekhoudkundig is).
Zovelen van ons hebben OO willen gebruiken, maar we willen nog steeds veilige opslag van onze gegevens. Wat is er veiliger dan onze gegevens op dezelfde manier op te slaan als het gewaardeerde boekhoudsysteem? Het is een aantrekkelijk vooruitzicht, maar we lopen allemaal tegen dezelfde valkuilen aan. Zeer weinigen hebben de moeite genomen om aan OO-persistentie te denken in vergelijking met de enorme inspanningen van de RDB-industrie, die het voordeel heeft gehad van de traditie en positie van de boekhouding.
Prevayler en db4o zijn enkele suggesties, ik weet zeker dat er andere zijn waar ik nog nooit van heb gehoord, maar geen enkele leek de helft van de pers te krijgen als, laten we zeggen, winterslaap.
Het opslaan van uw objecten in goede oude bestanden lijkt niet eens serieus te worden genomen voor toepassingen voor meerdere gebruikers, en vooral voor webtoepassingen.
In mijn dagelijkse strijd om de kloof tussen OO en RDB ik gebruik OO sluit zo veel mogelijk, maar proberen om de erfenis tot een minimum beperken. Ik niet vaak gebruikt SP. Ik zal de geavanceerde vraag spullen alleen in aspecten gebruiken die lijken op de boekhouding.
Ik zal gelukkig worden mooie locatie, bij de kloof voorgoed gesloten. Ik denk dat de oplossing zal komen wanneer Oracle lanceert iets als “Oracle Object aanleg Base”. Om echt aanslaan, dan moet het een geruststellende naam hebben.
23, Autoriteit 2%
Soms, uw toepassing en datalaag zijn niet zo nauw verbonden. Bijvoorbeeld, kunt u een telefoonrekening applicatie. U maakt later een aparte applicatie die monitoren telefoon gebruik om a) beter adverteren om u b) het optimaliseren van uw telefoon plan.
Deze toepassingen hebben verschillende belangen en informatie-eisen (zelfs de data komt uit dezelfde database), dan zouden ze verschillende ontwerpen rijden. Uw code base kan uiteindelijk een absolute puinhoop (in beide programma’s) en een nachtmerrie te handhaven als je laat de database drijven de code.
24, autoriteit 2%
Toepassingen die domeinlogica zijn gescheiden van de gegevensopslag logica aanpasbaar aan elk type gegevensbron (database of anderszins) of UI (web of vensters (of Linux etc.)) applicatie.
Uw vrijwel vast te zitten in de database, dat is niet slecht als je met een bedrijf die tevreden is met de huidige database systeem je gebruikt. Echter, omdat databases evolueren overwerk kan er een nieuwe database systeem dat is erg netjes en nieuw die uw bedrijf wil gebruiken. Wat als ze willen overstappen naar een web services methode voor toegang tot de gegevens (zoals service-georiënteerde architectuur eens doet). Je zou kunnen hebben naar de haven uw opgeslagen procedures all over the place.
Ook het domein logica abstracts weg de UI, die meer belangrijk is in grote complexe systemen die ooit hebben evoluerende gebruikersinterfaces (vooral wanneer ze voortdurend op zoek zijn naar meer klanten) kunnen zijn.
Ook, terwijl ik het ermee eens dat er geen definitief antwoord op de vraag van de opgeslagen procedures versus domein logica. Ik ben in het domein logica kamp (en ik denk dat ze winnen in de tijd), omdat ik geloof dat uitgebreide opgeslagen procedures zijn moeilijker te onderhouden dan uitgebreide domein logica. Maar dat is een heel ander debat
Antwoord 25
Ik denk dat je gewoon bent gewend om een specifiek soort applicatie te schrijven en een bepaald soort probleem op te lossen. Je lijkt dit aan te vallen vanuit een “database eerst” perspectief. Er zijn veel ontwikkelaars waar gegevens worden bewaard in een database, maar prestaties hebben geen topprioriteit. In veel gevallen vereenvoudigt het plaatsen van een abstractie over de persistentielaag de code aanzienlijk en zijn de prestatiekosten geen probleem.
Wat je ook doet, het is geen OOP. Het is niet verkeerd, het is gewoon geen OOP, en het heeft geen zin om je oplossingen toe te passen op elk ander probleem dat er is.
Antwoord 26
Interessante vraag. Een paar gedachten:
- Hoe zou u unit-testen als al uw bedrijfslogica in uw database zat?
- Zouden wijzigingen in uw databasestructuur, met name wijzigingen die van invloed zijn op meerdere pagina’s in uw app, geen groot gedoe zijn om in de hele app te veranderen?
Antwoord 27
Goede vraag!
Een benadering die ik liever heb, is om een iterator/generator-object te maken dat instanties van objecten uitzendt die relevant zijn voor een specifieke context. Gewoonlijk bevat dit object een aantal onderliggende databasetoegangsdingen, maar dat hoef ik niet te weten wanneer ik het gebruik.
Bijvoorbeeld
Een AnswerIterator-object genereert AnswerIterator.Answer-objecten. Onder de motorkap itereert het over een SQL-instructie om alle antwoorden op te halen, en een andere SQL-instructie om alle gerelateerde opmerkingen op te halen. Maar wanneer ik de iterator gebruik, gebruik ik gewoon het Answer-object dat de minimale eigenschappen voor deze context heeft. Met een klein beetje skeletcode wordt dit bijna triviaal om te doen.
Ik heb gemerkt dat dit goed werkt als ik een enorme dataset heb om aan te werken, en als ik het goed doe, krijg ik kleine, tijdelijke objecten die relatief eenvoudig te testen zijn.
Het is eigenlijk een dun laagje vernis over de databasetoegang, maar het geeft me nog steeds de flexibiliteit om het te abstraheren wanneer dat nodig is.
Antwoord 28
De objecten in mijn apps hebben de neiging om een-op-een te relateren aan de database, maar ik merk dat het gebruik van Linq To Sql in plaats van sprocs het veel gemakkelijker maakt om gecompliceerde query’s te schrijven, vooral door ze op te bouwen met de uitgestelde executie. bijv. van r in Images.User.Ratings waar etc. Dit bespaart me het proberen om verschillende join-instructies in sql uit te werken en Skip & Take for paging vereenvoudigt ook de code in plaats van het rijnummer & ‘over’-code.
Antwoord 29
Waarom stoppen bij entiteitsobjecten? Als u de waarde met entiteitsobjecten niet ziet in een app op bedrijfsniveau, voert u uw gegevenstoegang gewoon uit in een puur functionele/procedurele taal en sluit u deze aan op een gebruikersinterface. Waarom niet gewoon alle OO “pluisjes” wegknippen?