Vraag Wat zijn de voor- en nadelen van plug-in gebaseerde architectuur?


Ik wil het architectuurontwerp doen voor een software die kan worden gebruikt om verschillende software van derden (uitvoerbaar) onder één platform te integreren.

Standaard projecttypen worden standaard aan het platform toegevoegd. Het projecttype definieert de manier waarop de verschillende software zal worden uitgevoerd en hun invoer- en uitvoerbestanden.

De gebruiker kan het beschikbare standaardprojecttype aanpassen en dat wordt toegevoegd aan het platform als een nieuw projecttype dat een nieuwe aangepaste uitvoeringsstroom definieert.

Het zou ook de eenvoudige uitbreiding en aanpassing van de functies moeten ondersteunen. Ik lees dat de plug-in gebaseerde architectuur beide ondersteunt.

Wat zijn de voor- en nadelen van plug-in gebaseerde architectuur? Hebben we een betere architectuur die voor dit soort scenario's kan worden gebruikt?

Bij voorbaat bedankt:)


23
2018-05-12 11:43


oorsprong


antwoorden:


De voordelen van een pluggable systeem zijn

  • uitbreidbaarheid: de applicatie kan dynamisch worden uitgebreid met nieuwe functies.
  • parallelle ontwikkeling: aangezien functies kunnen worden geïmplementeerd als afzonderlijke componenten, kunnen ze parallel worden ontwikkeld door verschillende teams.
  • duidelijke ontwikkelingsrichting: aangezien het plug-inraamwerk in het ideale geval een goed gedefinieerde interface en documentatie biedt voor plug-inscanners, hebben ontwikkelaars een duidelijk stappenplan voor ontwikkeling.
  • eenvoud: een plug-in heeft meestal één functie en ontwikkelaars hebben dus één focus

Maar sommige van deze sterke punten zijn ook zwakke punten:

  • uitbreidbaarheid: anticipeert de interface van de plug-in op de manieren waarop plug-ins schrijven schrijvers wat de app moet uitbreiden, of wordt extensie beperkt. Het ontwerpen van uitbreidbaarheid om aan alle use-cases te voldoen, vergt vaak meerdere iteraties of een analyse met extreem goede vereisten.
  • onderhoudbaarheid: de aanbieder van het plugin-framework moet er niet alleen voor zorgen dat de plug-in interface voldoet aan ingesprongen use-cases, is duidelijk en goed gedocumenteerd, maar ook dat deze kan evolueren. Het beheren van versies en achterwaartse compatibiliteit met bestaande plug-ins kan erg moeilijk zijn. Hard genoeg dat veel praktische implementaties niet de moeite waard zijn, en de verantwoordelijkheid van plug-ins schrijven om hun plug-ins bij elke versie bij te werken.
  • complexiteit: hoewel elke plug-in werkt wanneer hij alleen wordt getest, kunnen interacties tussen plug-ins nieuwe problemen veroorzaken, waarbij bugs alleen verschijnen bij bepaalde combinaties van plug-ins.
  • testen: het testen van plug-ins kan moeilijk zijn als het plug-insysteem geen enkele vorm van mock-plugin-runner biedt voor testen, wat soms niet mogelijk is en testen alleen mogelijk is door de plug-in echt uit te voeren, wat de ontwikkeling vertraagt.
  • kunstmatige scheiding: een plug-in heeft typisch één focus, maar wat een enkele focus vormt wordt bepaald door de plugin api-provider. Als een schrijver van plug-ins ontdekt dat hij een plug-in nodig heeft die redelijkerwijs 2 dingen (zoals gedefinieerd door de plug-in api) in nauwe tandem kan doen, kan hij uiteindelijk twee plug-ins implementeren en manieren vinden om communicatie tussen hen te bieden die momenteel niet wordt aangeboden door de api. Hij moet dan rond werken of tegen het plugin-framework.

Het ontwerpen van een goede pluginomgeving heeft veel van dezelfde uitdagingen als het ontwerpen van een goede bibliotheek. Als u zowel de omgeving als de plug-ins zelf produceert, is dat niet zo erg omdat u alle plug-ins kunt bijwerken terwijl de omgeving zich ontwikkelt, maar als de plug-in api voor iedereen toegankelijk is, dan moet u zorgvuldig plannen en uitvoeren om het ontwerp te krijgen recht om te voorkomen dat teveel plug-ins worden herschreven als de omgeving evolueert.

"Tweede systeem syndroom"beschreven door Fred Brooks bepleit dat het ontwikkelde tweede systeem vaak overdreven generiek is, gericht op ultieme flexibiliteit, soms met het produceren van een" platform binnen een platform "/"innerlijk platformeffect"Een pluggable ontwerp wordt vaak gezien als een uitweg wanneer vereisten niet bestaan ​​of ondergespecificeerd zijn. Om dit te compenseren, is de software zo flexibel mogelijk gemaakt om te proberen om te gaan met" alles wat meespeelt ".

Het is fantastisch als dit een somber beeld schetst - insteekbare systemen kunnen fantastisch zijn en veel sterke punten bieden, maar ze hebben een hoge prijs. Voordat u in een pluggable systeem duikt, is het verstandig om vereisten op te stellen voor alle plug-ins die u nodig hebt om de vereiste functionaliteit te dekken. Dit zal u dan helpen beslissen of het inplugbare ontwerp de moeite waard is, of dat een eenvoudigere aanpak even goed zou kunnen dienen.


40
2018-05-17 18:56



De voordelen van een plug-inarchitectuur is natuurlijk de toename in flexibiliteit. Hierdoor kunnen andere ontwikkelaars uw applicatie uitbreiden op manieren die niet op de eerste plaats verwachtten. Merk op dat er verschillende plugin-architectuur is, variërend van flexibel tot extreem flexibel. De meest flexibele is een Full Plug-in-architectuur, die wordt gebruikt in verduistering.

Het nadeel is dat om echt flexibel te zijn, je een solide raamwerk moet ontwikkelen dat bestaat uit laden, lossen en communicatie tussen plug-ins. Er is ook een lichte prestatieoverhead in de communicatie tussen plug-ins.

Voor een bespreking over het maken van een plug-in-architectuur, kijk eens naar deze vraag.


5
2018-05-16 19:50



Hoewel het niet eenvoudig is om op plug-ins gebaseerde architectuur te onderhouden, waarom ontwikkelen mensen zich dan op zo'n manier? Omdat het nog steeds beter is dan andere "vaste" benaderingen. Stel dat uw vereisten na elkaar veranderen en dat het ontwerp moet worden opgelost, en bedenk dan wat er met andere benaderingen zal gebeuren?

Het beste hieraan is parallelle ontwikkeling. Wanneer de klant een aantal functies ZO VLUG MOGELIJK wil, kunnen ontwikkelaars parallel werken en hun code aansluiten als Plug-ins / Componenten. In principe biedt Plug-n-Play-architectuur flexibiliteit met complexiteit, maar voor de eerste keer is complexiteit een probleem. Zodra uw team zich er prettig bij voelt, is het gemakkelijk voor hen om code, bugs enz. Af te handelen ...

Wanneer u verschillende applicaties van derden wilt integreren, zoals u al zei, is het beter om het te ontwikkelen als plug-in OF component / service. (Ik wil je niet in de war brengen SOA kan van belang zijn.) Zodat u de service / plug-in aan / uit kunt zetten wanneer deze niet nodig is. Zelfs jij kunt hiervan profiteren als je dat wilt SAAS (Software As A Service) -model, waarbij u inkomsten genereert voor elke verschillende service / functie :).

Ter referentie kunt u de volgende JAVA-kaders controleren. Er zijn veel ESB's beschikbaar die componenten / service gebaseerde plug-n-play-architectuur biedt.

Ik hoop dat dit helpt.

bedankt.


3
2018-05-20 15:08



U vindt de voordelen en een klein plug-in framework waar u gebruik van kunt maken verbind tekst


1
2018-05-15 05:56