Strukturierung einer winforms C# - Lösung

Question

So bin ich bei der Neuorganisation eines winforms C# - Lösung zum entkoppeln und machen es Reiniger und mehr organisiert.Die Lösung verfolgt einen kleine Unternehmen Aufträge,etc ..

Ich habe gebrochen heraus die Projekte so weit in

App.Ansicht - alle GUI-Bezogenen Code
App.Daten - nur Daten, Strukturen und Schnittstellen.Keine andere code-Implementierung
App.BusinessLogic - alle-business-Logik-code, die hat keine GUI Referenzen

Ich habe einige Klassen, die ich nicht herausfinden kann, wo Sie hingehören.Bitte lassen Sie mich wissen, Ihre Gedanken dem Projekt jede Klasse gehen sollten, oder wenn es ist ein weiteres Projekt, das sollte für dieses erstellt.

1. Eine Klasse, ruft Benutzer-Einstellungen aus einer Datenbank
2. Eine Klasse, ruft statische Daten aus unserer statischen Daten-server und gibt Sätze von Daten Ergebnisse.
3. Eine Klasse, die bringt Benutzer-Berechtigungen
4. Eine model-Klasse, die speichert eine Hash-Tabelle der Aufträge
5. Eine Klasse, die E-Mails, Nachrichten an eine user-Aktion

Answer 1

Tatsächlich, ich glaube, Sie haben sich die Dinge ein wenig abseits von einem traditionellen geschichteten Architektur.Normalerweise werden die Modelle Ihrer Daten, die Ihre Anwendung auf würde gehalten werden in eine business-Schicht, zusammen mit dem code, um mit Ihnen arbeiten.Ihre Daten Ebene würden sowohl die Datenmodelle von der Persistenz-framework und den code für die Interaktion mit der Rahmen.Ich denke, das könnte eine Quelle der Verwirrung zwischen den vorgeschlagenen Standorten der Klassen und Ihre Reaktion auf Ihre Kommentare.

Aus dieser Perspektive alles, was holt oder bringt, möchte unbedingt sein, die sich in Ihrem Daten-layer -- es ist der Zugriff auf Daten in den persistenten Speicher.Was ruft es sind schließlich umgewandelt in die business-Schicht-Objekte, die Ihre business-Logik arbeitet.Die Dinge sind konzeptionelle Modelle-wie ein Tisch-Aufträge-oder business-Aktionen gehören in der business-Schicht.Ich Stimme mit @Adron, vielleicht die gleiche Verwirrung darüber, wo (3) geht-je nachdem, was es tatsächlich ist.

Genauer gesagt:

1. Benutzereinstellungen business Objekte, die Sache, die ruft Sie ist ein Daten-layer-Objekt.
2. Die statischen Daten der Karten auf ein business Objekt (Tabelle oder view oder so etwas), die Sache, greift auf den externen server ist ein Daten-layer-Objekt.
3. Der Anspruch ist ein business-Objekt, das Ding, die ruft es ist die Daten-Schicht-Objekt.
4. Eine Tabelle der Bestellungen ist ein business-Objekt
5. E-Mail-Versand ist eine business-Aktivität, so ist die Sache, die mails Menschen ist ein business-Objekt

[EDIT] Meine generalisierte 3-Tier-Architektur für (einfache) web-apps

DataAccessLayer

Dies würde meine TableAdapters und stark typisierte DataTables und Fabriken, die wiederum Zeilen meiner DataTables in business-Objekte in pre-LINQ-Projekte.Mithilfe von LINQ-dies würde mein DataContext-und designer-generierten LINQ-Entitäten.

BusinessLayer

Dies würde auch jede business-Logik, einschließlich der Validierung und security.In pre-LINQ-diese wäre meine business-Objekte und alle anderen Klassen, die die Implementierung der Logik der Anwendung.Mithilfe von LINQ-diese sind die partiellen Klasse Implementierungen von meiner LINQ-Entitäten zu implementieren, Sicherheit und Validierung zusammen mit allen anderen Klassen zu implementieren business-Logik.

Präsentation

Diese meine web-forms-im Grunde genommen die Benutzeroberfläche der app.Ich weiß sind einige der Validierungslogik in den Formen als eine Optimierung, obwohl diese auch validiert in der BL.Dies würde auch alle Bedienelemente.

Hinweis: Dies ist die logische Struktur.Die Projekt-Struktur in der Regel Spiegel, aber es gibt einige Fälle, wie die verbindungen zu Webdiensten, dass kann direkt in die web-Projekt, obwohl logischerweise die Komponenten sind wirklich in der BL/DAL.

Hinweis: Ich werde wahrscheinlich zu bewegen MVC über 3-Tier einmal ASP.NET MVC ist in der Produktion.Ich habe einige persönliche Projekte in Ruby/Rails, und ich mag wirklich das MVC-Paradigma für web-apps.

Answer 2

Sie haben angegeben, dass die App.Sollten die Daten enthalten nur die Daten, Strukturen und Schnittstellen keine Implementierung von code, die ist in Ordnung, wenn Sie das tun wollen, aber das lässt Sie nirgends zu setzen Sie Ihre Datenbank-Zugriff-code, außer in Ihrer App.BusinessLogic Montage.

Vielleicht ist Sie wirklich brauchen, um den umbenennen-App.Daten zu App.Modell (oder etwas ähnliches), und eine neue App.DataAccess Montage, dass die Gespräche, die Datenbank (vielleicht Implementierung eines Repository-Musters).Wenn dies erledigt ist, würde ich aufteilen, Dinge wie diese:

1. App.DataAccess
2. App.DataAccess
3. App.DataAccess
4. App.Modell
5. App.BusinessLogic

Answer 3

Würde ich wahrscheinlich gehen mit

1. Daten
2. Daten
3. Daten, obwohl ich bin nicht ganz sicher, was die Klasse tut
4. Daten
5. BusinessLogic

Answer 4

1. -> App.Daten
2. -> App.Daten
3. -> App.BusinessLogic oder in der App.Daten - nicht sicher, was genau das bedeutet.
4. -> App.BusinessLogic
5. -> App.BusinessLogic