Ich hänge mal ein Bild an "myCode":
Tool1 isi ein erstes Anwendungsprogramm.
Tool2 ist ein zweites Anwendungsprogramm (selbe Funktion wie 1 nur andere API syntax).
Die Funktionalität beider Tools kann mittels plugin dlls erweitert werden.
Um nun zu verhindern, dass man diesselbe Erweiterungsfunktionalität zweimal programmieren muss, einmal mit API1 1 für Tool 1 und dann nochmal mit API 2 für Tool 2 würde ich gerne eine Art Interface dazwischenschalten, so dass die Erweiterungsfunktionalität unabhängig von der API der Tools programmiert werden kann und dann (möglichst einfach) an die APIs der Tools adaptierbar ist.
Wie so eine plugindll aussehen kann, z.B. für z.B. Tool1, seht ihr hier:
namespace ApplicationNamespace
{
public class MyName : Vererber
{
public MyName()
{
//My funktionality
}
protected override void OnDo1()
{
//My funktionality
}
protected override void OnDo2()
{
//My funktionality
}
protected override void OnDo3(ABC variable)
{
//My funktionality
}
protected override void OnDo4(int a)
{
//My funktionality
}
usw.
}
}
Ist bei beiden Tools sehr ähnlich, nur die Namen der Methoden unterscheiden sich teilweise.
Ich möchte quasi "My functionality" zunächst dll-unabhängig implementieren und dann später in die jeweilige API-Abhängigen Aufrufe reinbringen.
Ich nehme an, das man hier eine Art Zwischenschicht implementieren müsste (siehe IF im Bild), innerhalb derer man dann zwischen beiden Tools wählen kann.
Liege ich da richtig und hättet Iht hier einen Tipp, wie bzw. mittels welcher Herangehensweise man das realisieren könnte ?
Les Dir Dein Thema durch, stell Dir vor Du hast keinerlei Hintergrundinfos: würdest Du selbst auf den Thread antworten können? 😃
Schaue ich mir Dein Bild an und beachte Dein Kommentar
(selbe Funktion wie 1 nur andere API syntax)
komm zumindest ich zu dem Entschluss: Dein Wunsch ist mit der Realität nicht kombinierbar. Du musst Deinen Code individuell pro Pluginsystem anpassen/integrieren (zumindest die Schnittstelle).
Das heisst, dass man i.d.R. extra Projekte anlegt, in denen man dann den Code in die Plugins integriert.
MyName.MyApp - Dein Code
MyName.MyApp.Tool1.Plugin - Plugintegration Tool 1
MyName.MyApp.Tool2.Plugin - Plugintegration Tool 2
Wenn Du meinen Hinweis aus den anderen Threads, dass Du Dir die Basics zum Aufbau der Projekte/Namespaces anschaust, beachtet hast, dann erkennst diese Struktur ja wieder.
Das ist im Endeffekt die Basis quasi jeder Provider in .NET, Java, Co..
Beispielweise
Microsoft.EntityFrameworkCore
Microsoft.EntityFrameworkCore.SqlServer
Microsoft.EntityFrameworkCore.Sqlite
Microsoft.EntityFrameworkCore.InMemory
Technisch gesehen auch nichts anderes als dass EFCore andere "Tools" integriert.
Ganz wichtige Grundlage in jeder Art von Software Entwicklung: Dein "Kerncode" hat keine Abhängigkeit zu seinen Nutzern.
Daher ist hier als Beispiel der SqlServer auch nicht Teil von Microsoft.EntityFrameworkCore
, sondern eben ausgelagert.
Was Du da im Foto zeigst sieht aus, als ob Du es genau anders rum vor hast/hattest.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code