Ich bin bei der Arbeit auf die folgenden Fragen gestoßen, und ich habe nicht die Erfahrung oder das Wissen, um sie zu beantworten. Ich hoffe, dass einige von Ihnen weisere Leute in der Lage sein könnten, mir in die richtige Richtung zu zeigen , alle Antworten werden sehr geschätzt!
Szenario
Wir haben zwei Aspekte des Geschäfts mit getrennten Datenbanken, Personalwesen und Betriebsbereichen (Homecare).
Human Resources verfolgt die Mitarbeiter, Schichtpläne, Abwesenheit, Bezahlung usw. des Unternehmens. Homecare hält Kundeninformationen, Hausbesuche, Besuchstermine und die für den Besuch verantwortlichen Mitarbeiter fest.
Diese beiden Systeme sind getrennt und wir suchen derzeit nach Möglichkeiten, sie zu integrieren.
Außerdem untersuchen wir, wie wir unseren Code, der diese beiden Datenbanken betrachtet, in wiederverwendbare, organisierte Bibliotheken organisieren können.
Wir haben drei Anwendungen, die eine HumanResources.dll wiederverwenden, die für die Kommunikation mit einem EF 4-Objektkontext verantwortlich ist, der in der Bibliothek enthalten ist. Der Objektkontext ist fast ein Spiegelbild der Datenbank, wie sie ist.
Fragen
Wir werden gerade eine vierte Anwendung hinzufügen, die Daten in der HR-Datenbank verwendet.
Tun wir:
Erstellen Sie ein neues EF-Datenmodell, verantwortlich für die Bereitstellung von Informationen dass nur die Anwendung braucht, während Duplizieren einiger gebräuchlicher Entitäten wie z als Mitarbeiter.
ODER
Fügen Sie die neuen Entitäten / Tabellen zum schon großes Modell und akzeptiere es werde groß werden.
Längerfristig müssen wir die Schichtmusterinformationen in der HR-Datenbank mit den Client-Besuchen in der Datenbank der Betriebsbereiche (Homecare) in einer fünften Anwendung verknüpfen.
Wir haben eine Vorstellung davon, was wir tun könnten; wir haben uns folgendes ausgedacht:
Erstellen Sie eine Ebene, die zwischen den HumanResources Objektkontext und Homecare Objekt Kontext, verantwortlich um die zwei Datensätze zu verbinden zusammen.
Gibt es andere Ansätze, die uns nützen könnten?
Eine Fassade ist im Grunde ein Adapter für ein komplexes Subsystem. Da Sie zwei Subsysteme haben, würde ich empfehlen, drei Klassen mit den folgenden Funktionalitäten zu erstellen:
HumanResourcesFacade : Eine Klasse, die alle Funktionen von "Human Resources" umschließt. Die Aufgabe dieser Klasse besteht darin, Methoden zur Verfügung zu stellen, die jede Arbeitseinheit ausführen, für die die Personalverwaltung verantwortlich ist, ohne dem Kunden Informationen über die Anwendung "Human Resources" offenzulegen.
HomecareFacade : Eine Klasse, die alle "Homecare" -Funktionen abdeckt. Die Aufgabe dieser Klasse besteht darin, Methoden zur Verfügung zu stellen, die jede Arbeitseinheit ausführen, für die die Homecare-Anwendung zuständig ist, ohne dem Client Informationen über die Homecare-Datenbank offen zu legen.
ApplicationFacade : Eine Klasse, die sowohl HumanResourcesFacade als auch HomecareFacade umschließt und Ihren Clients öffentliche Methoden zur Verfügung stellt, die keine Kenntnis der inneren Abläufe einer der beiden verschachtelten Fassaden benötigen. Die Aufgabe dieser Klasse ist es zu wissen: (a) welche der beiden verschachtelten Fassaden für jeden Client-Aufruf verantwortlich ist, (b) den Aufruf des Clients der ApplicationFacade durch einen Aufruf der entsprechenden Methode auf der verschachtelten Fassade auszuführen und ( c) Übersetzen der von der verschachtelten Fassade empfangenen Daten in ein Format, das vom Client verwendet werden kann und unabhängig von den Datenformaten der verschachtelten Fassade.
Ich würde empfehlen, ein POCO-Objektmodell zu verwenden, um eine gemeinsame In-Code-Darstellung der Daten zu erstellen, die nicht von der tatsächlichen Persistenzimplementierung abhängig ist. Die von Adrian K vorgeschlagene Domänenmodelltechnik ist ein guter Ansatz, aber wenn Sie mit den Mustern und der Methodik nicht vertraut sind, kann es am Ende sehr verwirrend sein und viel länger dauern als Techniken, die intuitiver sind. Eine Alternative besteht darin, nur Datenobjekte und einen Data Mapper zu verwenden. Der Data Mapper nimmt grundsätzlich die Daten einer Datenquelle und wandelt sie in ein Objekt um, das nicht von der Datenquelle oder dem Mapper-Objekt abhängig ist. Ich habe einen Link unten eingefügt.
Eine Sache, die ich klarstellen möchte ist, dass, während ich gesagt habe, dass ApplicationFacade drei Jobs hat, ich nicht rate, dass Sie das Prinzip der einheitlichen Verantwortung . Ich meine nicht, dass die Klasse all diese drei Dinge alleine machen muss, sondern dass sie jeden Mechanismus, den Sie für die Ausführung dieses Prozesses verwenden, einkapseln sollte und dass keine anderen Teile der Anwendung auf diese Probleme von außerhalb des% -Zentrums zugreifen sollten. Code%. Zum Beispiel sollten Ihre Geschäftsobjekte nicht wissen, aus welcher Datenquelle sie erstellt wurden - diese Informationen sollten nicht von einem anderen Ort aus zugänglich sein als von der Klasse ApplicationFacade eingekapselt.
Klingt so, als müssten Sie eine ernsthafte Datenmodellierung vornehmen.
Sie brauchen es definitiv auf lange Sicht, damit Sie sich nicht in einen ernsthaften Streit stürzen. (Wenn es eine Sache gibt, die einen signifikanten Einfluss auf Ihre Fähigkeit hat, Systeme zu unterstützen / zu erweitern und das Geschäftswachstum zu unterstützen, ist das Datenmanagement). Das Gute an (Geschäfts-) Daten ist, dass Ihre Geschäftsinteressenten ein gutes Verständnis davon haben (oder sollten) und angemessen motiviert sind, Sie zu unterstützen. Der Wert, den eine solche Übung bringen wird, sollte ein einfacher Verkauf sein. Auch kurzfristig etwas davon zu haben, wird helfen.
Datenquellen, die mit Paketprodukten geliefert werden (Commercial Off The Shelf - COTS), sind nicht offen für Änderungen, ohne diese Systeme zu gefährden - aber das heißt nicht, dass Sie ETL und andere Datenbanken nicht zum Erstellen von Data Marts verwenden können die unterschiedliche Daten zusammenbringen. Bei dieser Art von Ansatz wird die Datenmodellierung und Datenzuordnung zwischen Systemen wichtig sein - aber auch das Timing.
Sie werden mehr Flexibilität mit internen Apps haben - aber Sie könnten taktischen Änderungen widerstehen, es sei denn, Sie haben einen sehr zwingenden Grund, sonst müssen Sie sie wahrscheinlich trotzdem noch einmal bearbeiten.
Als Teil dieser Übung sollten Sie das System der Aufzeichnung jedes einzelnen Datenelements berücksichtigen kommt es her? Wem gehört es? Sie können auf einer höheren Ebene beginnen, indem Sie ein konzeptionelles Datenmodell erstellen, das wahrscheinlich mehr mit logischen Datensätzen als mit spezifischen "Spalten" zu tun hat.
Verwenden Sie diese Informationen, um weitere Entscheidungen zu leiten.
Im Hinblick auf Ihren unmittelbaren Ansatz (und Ihre Frage): Im Allgemeinen würde man darüber nachdenken, eine Abstraktionsschicht zwischen Ihren Systemen und den Daten zu legen, damit die Anwendungen von Veränderungen abgefangen werden, wenn das passiert.
>Erstellen Sie ein neues EF-Datenmodell, das für die Bereitstellung von Informationen zuständig ist, die nur von der Anwendung benötigt werden, während Sie einige gängige Entitäten wie den Mitarbeiter duplizieren.
Das große Problem bei der Duplizierung besteht darin, die Daten in einen Zustand zu versetzen, der matschig ist - was der "echte" Datensatz ist. Dies kann dich leicht töten. Was sind die Vorteile dieses Ansatzes in Ihrem Kontext? Würdest du das aus Gründen der Unterstützung machen? Leichtigkeit der Entwicklung?
Es kommt sehr darauf an, was Sie unter Integration verstehen.
Vermeiden Sie, wenn möglich, direkt in die Datenbank für fremde Systeme zu schauen, Daten von einem System zum anderen zu replizieren oder direkte API-Aufrufe an das Quellsystem vorzunehmen. Das Leitprinzip sollte lauten: "Wenn ich System X durch System SuperX ersetze, wie einfach wäre es, die anderen Systeme in Betrieb zu halten".
Tags und Links architecture integration entity-framework-4 database-design facade