2016-06-29 12 views
0

Als letzte in .NET beteiligt, befürwortete Microsoft einen architektonischen Ansatz, bei dem man gegen eine Darstellung der Datenbank im Code - Datasets, Datatables usw. - programmierte. Dies entsprach ihrem automatisch generierten Code durch tools-basierten Ansatz. Sie haben niemals ein Rich Object Domain-Modell als Basis für Ihre Architektur befürwortet.Ist in .NET ein datenzentrischer Architekturansatz immer noch der Standard? Wenn nicht, was hat es ersetzt?

Hat sich diese Position geändert? Wird ein umfassender Domänenmodell-Architekturansatz von Microsoft befürwortet oder unterstützt, insbesondere aufgrund der Einführung von Entity Framework, oder wird ein datenzentrierter Ansatz immer noch befürwortet?

+0

Es gibt keine DataTable in .NET Core 1.0. Es bedeutet nicht, dass du deine eigenen nicht hacken kannst, aber es scheint ziemlich klar zu sein, in welche Richtung das geht. –

+0

@KooKiz Also bleibt die Frage bestehen. In einer nicht-funktionalen Anwendung wird nun welcher Ansatz befürwortet? Immer noch ein Transaktionsskript-Controller mit allen Logik gegen einige Darstellung der Datenbank arbeiten? Oder arbeitet man gegen ein Objektdomänenmodell, das die Logik enthält? Oder arbeitet man gegen etwas anderes? – Jon

+2

Ich glaube nicht, dass MS wirklich einen bestimmten Stil befürwortet. Sie haben Beispiele für die Verwendung von CQRS und Event-Sourcing, wenn Speicher dient. Die richtige Objektorientierung/Rich-Domain-Modellierung ist jedoch eine Kunst, und es ist schwierig, sie richtig zu machen, und einige ihrer Befürworter, wie zum Beispiel domänengesteuertes Design, scheinen mit eher anämischen Modellen zu enden. Vielleicht sind die Proben zu einfach. Auf jeden Fall denke ich, dass die * Wahrnehmung * einer datenzentrierten MS schwer zu erschüttern ist. Sie konzentrieren sich heutzutage auch mehr auf Open Source, aber das hilft nicht viel. –

Antwort

1

Entity Framework ist jetzt die empfohlene Datenzugriffslösung im Gegensatz zu ADO.NET. F # verfügt über Typanbieter und ermöglicht das Entwerfen domänenspezifischer Sprachen. Dies umfasst eine reichhaltige Programmierung.

Jetzt entfernt sich .NET Core von Werkzeugen und automatisch generierten Ansätzen. Es ist plattformübergreifend, agil und konzentriert sich darauf, was Open-Source-Communities seit Jahren tun.

Zusammengefasst: .NET dreht sich jetzt nicht um Datenbanken und Tools.

+0

Nirvin, vielen Dank. In einer nicht-funktionalen Anwendung wird nun welcher Ansatz befürwortet? Immer noch ein Transaktionsskript-Controller mit allen Logik gegen einige Darstellung der Datenbank arbeiten? Oder arbeitet man gegen ein Objektdomänenmodell, das die Logik enthält? Oder arbeitet man gegen etwas anderes? – Jon

1

Gemessen an diesem MSDN "Patterns and Practices" series book von 2012, haben sie eine reiche Domain-Modell-Ansatz für eine ganze Weile empfohlen.

Nicht, dass dies eine exklusive Empfehlung ist - Microsoft wechselte im Grunde genommen zu einer weniger eigenwilligen, richtigen Tool-für-den-richtigen-Job-Rede über so ziemlich alles, was sie bieten, und die datenzentrischen Tools sind immer noch da. Unabhängig davon wäre es selbstmörderisch, wenn sie allen anderen hinterherhinken und immer noch einen Daten-Code-Generierungs-basierten Ansatz bevorzugen.

[Bearbeiten] Sie sollten beachten, dass CQRS und/oder Event Sourcing nicht von einem reichen Domänenmodell ausgeschlossen sind, ganz im Gegenteil. CQRS-Befehle lösen umfangreiche Domänenlogik in Entitäten aus, die dann (reiche) Domänenereignisse ausgeben. Genau das beschreibt das Buch. Lass dich nicht vom Titel täuschen.

+0

Danke Guillaume. Der von Ihnen angegebene Link verweist nicht auf einen umfassenden Domänenmodellansatz. CQRS und Event Sourcing ist kaum das. Es ist ein ereignisgesteuerter Ansatz für Schreibvorgänge und ein datenzentrierter Ansatz für Lesevorgänge. Beachten Sie, dass ihre präskriptive Praxis nur auf der "Erkundungs" -Ebene ist. Ehrlich gesagt, ich bin fassungslos. – Jon

+0

@JonBadda die Artikelserie ist vier Jahre alt.Ich denke, es gibt kein Problem damit, dass es sich auf der Explorationsebene befindet. – jbl

+0

@JonBadda Sowohl CQRS als auch Event Sourcing kamen aus dem Domain Driven Design Bereich, der offensichtlich der * große * Rich Domain Ansatz ist. Ereignisbeschaffungsereignisse spiegeln selbst ein reiches Domänenmodell wider. – guillaume31