Bitte um Hilfe zum Verständnis von DomainModel / Services usw.

Question

Hallo

Ich habe bis jetzt immer die gesamte Entwicklung eines Projekts immer in einem Projekt untergebracht.

Da das Projekt, dass ich jetzt in Angriff nehmen möchte doch etwas größer wird, möchte ich mein Projekt aufteilen in mehrere Projekte. Soweit, so gut.

Was ich bis jetzt noch nicht durchschaut habe, ist wie ein vernünftiger Datenaustausch zwischen den Projekten stattfinden kann.

Etwas präziser: - Ein großes Projekt, dass mehrere Projekte vereinigt. Dazu sollen z.B. die gesamten Datenbank abfragen, updates, deletes, usw. in dem Projekt: DomainModel entstehen.

Aber wie ist der richtige Ansatz die Daten mit dem Projekt, dass die Formen hält auszutauschen.

Ich könnte natürlich in jeder "Form" das Projekt laden mit:

Dim myDomainModel as New DomainModel

Dim Customer As New ObservableCollection(of DomainModel.Customer)
Customer = myDomainModel.LoadCustomer

(Das ist nur als Bsp. Code gedacht)

Ich habe im Internet eben auch gefunden, dass anscheinend die Daten auch per Interface ausgetauscht werden.

Das durchschaue ich aber nicht & hoffe, dass mir da jemand mit einem Bsp. helfen kann.

DANKE - Schönes Wochenende noch

Answer 1

Hi Zero-G._

das ist natürlich keine Frage, die man Eben in einer Mail Beantworten kann.

Dem entsprechend hier mal ein paar Buch Vorschläge.

PoEA (die Patterns sind such auf Folwlers HP zu finden, es lohnt sich aber auch mal das Buch anzuschauen)

und Building Enterprise Applications...

Also Kostenlose Quellen kenne ich noch:

Prism

und

Microsoft Application Architecture Guide

Wo bei Prism die Weiterführung der Architekture Guide ist,

Zu einen einfachen Datenaustausch zwischen den "Projekten" kann man POCOs benutzen.

Grundlegend solltest du dich hinsetzen und bei Komplizierteren Projekten, einen Architekturentwurf machen.

MFG

Björn

Answer 2

Ich meine man kann bestimmt endlos überlegen und nachlesen was der richtige Ansatz sei. Diese Zeit geht von wirklicher Entwicklung ab.

Solange alles klar getrennt ist. Solange Redundanz vermieden wird. Solange die Codemenge annähernd die geringstmögliche ist. Solange es tut was es soll. Es benutzt werden kann und wird sind diese Diskussionen allermeist kontraproduktiv... Im wahrsten Sinne des Wortes. Nur eine Meinung.

Du würdest verkomplizieren anstatt möglichst zu vereinfachen. Als Warnung davor sich in einer Vielzahl von theoretischen Ansätzen zu verlieren die vielleicht in der realen Welt garnicht existieren.

Dein Ansatz das DomainModel zentral in einem Projekt unterzubringen ist doch gut? Haben diese Objekte dort einen Status oder nicht? Man könnte halt weitergehen und zwischen Forms, Fachlogikobjekten und Datenzugriffschicht unterscheiden. 

Answer 3

Danke euch vielmals für eure Tipps!

Sind zwar sehr unterschiedlich, aber haben beide einen interessanten Ansatz!

Ich markiere bewusst keine Antwort als "Antwort", da ich glaube, beide Ansätze haben recht.

Schönen Tag - lg