Ik weet dat dit misschien gek klinkt, maar ik vind het moeilijk om de noodzaak van een servicelaag en de verschillen met de bedrijfslaag te begrijpen.
Dus we gebruiken asp.net mvc 2 en hebben een gegevenstoegangslaag die alle query’s met de database doet en dan hebben we de bedrijfslaag met de bedrijfslogica en validaties die moeten worden uitgevoerd. Eindelijk hebben we de presentatielaag die in feite alle weergaven heeft. Daarnaast hebben we ook enkele helpers, DTO’s en viewmodel-klassen in verschillende mappen als onderdeel van onze bibliotheken. Maar ik heb geprobeerd over architectuur te lezen en het lijkt erop dat de servicelaag een belangrijk onderdeel is van een architectuur.
Alles wat ik begrijp is dat een servicelaag iets is dat alle functies aanroept.
Maar ik zie de noodzaak van een servicelaag in onze applicatie niet echt? Of misschien is het er al en kan ik het niet zien… Kan iemand met een voorbeeld uitleggen hoe een servicelaag belangrijk is? Hoe verschilt het van een bedrijfslaag, omdat wat ik heb gelezen behoorlijk op elkaar lijkt?
Als het in de eerste nodig is? Het enige dat we proberen te doen, is onze applicatie op de best mogelijke manier ontwerpen. Wat zijn uw gedachten en ervaringen ermee?
Antwoord 1, autoriteit 100%
Het draait allemaal om het ontkoppelen van uw app in op zichzelf staande stukken, elk gedefinieerd door de vereiste om één taak echt goed te doen.
Hiermee kunt u gespecialiseerde ontwerppatronen en best practices toepassen op elk onderdeel.
Het is bijvoorbeeld de taak van de bedrijfslaag om de bedrijfslogica te implementeren. Punt. Het blootleggen van een API die is ontworpen om door de presentatielaag te worden gebruikt, is niet zijn “zorg”.
Deze rol van tussenpersoon kan het beste worden vervuld door een servicelaag. Door deze gespecialiseerde laag buiten beschouwing te laten, kunt u veel meer gespecialiseerde patronen toepassen op elk afzonderlijk onderdeel.
Het is niet nodig om dingen op deze manier te ontwerpen, maar de opgedane ervaring van de gemeenschap geeft aan dat dit resulteert in een applicatie die veel gemakkelijker te ontwikkelen en te onderhouden is, omdat je precies weet wat elk onderdeel moet doen, zelfs voordat je begint de app te coderen.
Elke laag zou één taak heel goed moeten doen. De rol van tussenpersoon die de servicelaag vervult, is zo’n goed gedefinieerde taak en dat is de reden van zijn bestaan: het is een eenheid van complexiteit die steeds opnieuw op dezelfde manier wordt ontworpen, in plaats van het wiel opnieuw uit te vinden elke keer, om deze rol te manipuleren met de bedrijfslogica waar het niet thuishoort. Zie de servicelaag als een mappingcomponent. Het staat buiten de bedrijfslogica en hoort niet thuis in zijn klassen, of ook niet in de controllers.
Als gevolg van het feit dat u uit de bedrijfslogica bent weggelaten, krijgt u eenvoudigere bedrijfsobjecten die gemakkelijker te gebruiken zijn door andere toepassingen en services die het “bedrijf” gebruikt.
ASP.NET MVC is niets anders dan een platform waarmee u uw apps als gespecialiseerde componenten kunt schrijven.
Als gevolg van dit toenemende begrip van hoe componenten te specialiseren, evolueren programma’s van een oerkom soep en spaghetti naar iets anders en vreemds. De complexiteit die ze aankunnen, terwijl ze nog steeds eenvoudige structuren gebruiken, neemt toe. De evolutie komt op gang. Als het leven iets is om langs te gaan, moet dit goed zijn, dus houd de bal aan het rollen.
Antwoord 2, autoriteit 46%
Misschien vindt u de term Architecture Astronautinteressant.
Het punt is dat je niet verstrikt raakt in al deze “lagen” waar mensen omheen draaien. Elke keer dat je een andere laag in de applicatie had, moet er een doel in zitten.
Sommige mensen combineren bijvoorbeeld met succes de concepten van een laag voor gegevenstoegang en bedrijfslogica in één. Het is niet geschikt voor elke oplossing, maar het werkt perfect voor veel van hen. Sommige mensen combineren zelfs presentatie met zakelijk… wat in veel kringen een belangrijk nee is, maar nogmaals, het kan perfect zijn voor de betreffende behoefte.
Kortom, het probleem dat u oplost, zou de structuur van de toepassing moeten bepalen. Als andere applicaties met die van u moeten worden geïntegreerd, moet mogelijk een servicelaag worden toegevoegd. Dit kan de vorm aannemen van eenvoudige webformulieren waarop anderen gegevens kunnen posten of het kan verder gaan om volledig te zijn op webservices. Er kunnen zelfs situaties zijn waarin u wilt dat de servicelaag de primaire locatie is voor meerdere presentaties.
Je kunt het zo ingewikkeld maken als je wilt, maar een goede vuistregel is om het simpel te houden tot
de complicaties worden noodzakelijk.
Antwoord 3, autoriteit 41%
In sommige ontwerpen wordt de servicelaag niet gebruikt door de presentatielaag.
De servicelaag wordt aangeroepen door andere applicaties die de bedrijfs- en datatoegangslagen in de applicatie willen gebruiken.
In zekere zin is de servicelaag een andere front-end los van de presentatielaag.
Bekijk het architecturale diagramhier. De gebruikers benaderen de applicatie via de presentatielaag. En de externe systemen benaderen de applicatie via de services-laag. De presentatielaag en de dienstenlaag praten met de applicatiegevel in de bedrijfslaag.
Als een voorbeeld van wat die andere ‘externe systemen’ zouden kunnen zijn, noemen webservices en WCF-services de servicelaag. Een andere webtoepassing zou de servicelaag van deze toepassing kunnen aanroepen in een webserviceaanroep. Dit zou een manier zijn om ervoor te zorgen dat beide apps dezelfde bedrijfslogica toepassen en dat eventuele wijzigingen in de bedrijfslogica worden weerspiegeld in beide apps.
Zoals Chris Lively aangeeft, moet je je niet laten meeslepen door het maken van lagen. Ik zou aanraden om alleen de lagen te maken die nuttig zijn in uw toepassing. In mijn ervaring is de behoefte aan een servicelaag niet frequent, maar de behoefte aan een bedrijfslaag is zeer frequent.
Antwoord 4, autoriteit 22%
De servicelaag is meestal geconstrueerd in termen van discrete bewerkingen die voor een klant moeten worden ondersteund.
Een servicelaag kan bijvoorbeeld het aanmaken van een account aan het licht brengen. Terwijl de bedrijfslaag kan bestaan uit het valideren van de parameters die nodig zijn bij het maken van een account, het construeren van gegevensobjecten die moeten worden bewaard, enz.
Vaak gebruikt de servicelaag een procedure- of transactiescript-stijlcode om de zakelijke en/of logische lagen te orkestreren.
Als u dit weet, realiseert u zich misschien dat uwbedrijfslaag echtook een servicelaag is. Op een gegeven moment, het punt van waaruit je deze vraag stelt, is zo’n punt, het onderscheid is meestal semantisch.
Antwoord 5, autoriteit 19%
Vanuit mijn perspectief stelt een servicelaag u in staat uw presentatielaag te isoleren van uw bedrijfslaag, op dezelfde manier waarop de bedrijfs- en gegevenstoegangslaag u isoleert van hoe u de gegevens bewaart.
In uw bedrijfslaag zou u dingen plaatsen die cruciaal zijn voor uw ‘bedrijf’. Een gekunsteld (en waarschijnlijk slecht bedacht voorbeeld) zou zijn om dat de plaats te hebben waar bijvoorbeeld kortingsprijzen op een product voorkomen.
Met de servicelaag kunt u de interface verder scheiden van de business. Of zelfs andere bedrijfslagen verwisselen, afhankelijk van de veranderende scenario’s van het bedrijf.
Niet elke applicatie heeft er echter een nodig (er komen veel variabelen bij kijken), te veel architectuur kan complexiteit introduceren die uw team misschien niet nodig heeft.
Antwoord 6, autoriteit 5%
Kijk eens wat Randy Stafford zegt over Service Layer in het “P of EAA” Book
http://martinfowler.com/eaaCatalog/serviceLayer.html
Een servicelaag definieert een
toepassingsgrens [Cockburn PloP]
en de reeks beschikbare bewerkingen
vanuit het perspectief van interfacing
klant lagen. Het omvat de
de bedrijfslogica van de applicatie,
het controleren van transacties en
coördinerende reacties in de
uitvoering van haar activiteiten.
Antwoord 7, autoriteit 5%
Eenvoudig. Gebruik een servicelaag om uw bedrijfslogica aan een klant bloot te stellen.
Vraag jezelf af:
Moet de servicelaag veranderen bij het wijzigen van de bedrijfslogica?
Als het antwoord “niet altijd” is, is een servicelaag nodig.
Antwoord 8, autoriteit 3%
Ik weet dat deze thread oud is, maar een handig ding dat ik in de servicelaag heb gedaan, is het afhandelen van transacties (de bedrijfslaag zou niet moeten weten hoe ze moeten omgaan met terugdraaiingen, het bestellen van bewerkingen, enz.).
p>
Een ander ding dat ik heb gedaan, is het gebruiken om te vertalen tussen domeinentiteiten en DTO’s. De bedrijfslaag behandelt het domeinmodel, maar ik heb de gegevens teruggegeven aan de presentatielaag in de vorm van DTO’s (in sommige gevallen was het om verschillende redenen niet praktisch om het hele domeinmodel bloot te stellen aan de presentatielaag), dus de servicelaag handelt deze toewijzing af.
Uiteindelijk zie ik de bedrijfslaag als fijnmaziger, terwijl de servicelaag grover kan zijn omdat deze meerdere bewerkingen in de BLL kan aanroepen en oproepen binnen één serviceaanroep kan bestellen.
Antwoord 9
Ja, en ik wil er ook op wijzen dat de servicelaag een goede plaats is voor authenticatie, zowel op rollen als op gebruikers gebaseerd.