Linq zu SQL ORM 3-Schicht-Frage

Question

Ich entwerfe dieses HR-System (Desktop-basiert) für eine mittelgroße Organisation. Die Sache ist, dass ich alle Tabellen entworfen habe und plante, das O/RM in VS2008 zu verwenden, um die Entitätsklassen zu erzeugen (dies ist das erste Mal, dass ich mit OR/M arbeite; tatsächlich ist dies mein erstes "großes" Projekt.) Ich wollte die App mit 3 Ebenen erstellen (einer der Programmierer der Firma schlug nicht 3, sondern 4 oder 5 Ebenen vor), aber nachdem ich ziemlich viele Blogeinträge und viele Fragen hier gelesen habe, habe ich erkannt, dass das nicht ganz so ist Dies ist mit LINQ to SQL sehr einfach, da der Datenkontext funktioniert und es schwierig ist, Objekte zwischen den Ebenen mit LINQ to SQL zu übergeben.

Wahrscheinlich werde ich nur die Entity-Klassen verwenden, die vom VS2008 ORM generiert wurden, und jede Validierung und Geschäftslogik in Teilklassen hinzufügen. Aber das wäre 2 Schichten oder nicht? Die App wird von ungefähr 10 Benutzern verwendet werden, daher glaube ich nicht, dass der 2-Ebenen-Ansatz ein großes Problem ist.

In Zukunft wird ein webbasiertes Front-End entwickelt, damit sich Kandidaten online auf Jobs bewerben können. Ich möchte es so skalierbar wie möglich entwickeln. Aber die Wahrheit ist, ich habe nicht viel Zeit zu verschwenden, um eine Entscheidung zu treffen, Zeiten laufen hehe.

Nachdem all das gesagt wurde, sollte ich nur die Entitäten verwenden, die vom VS2008 ORM generiert wurden?

So jeder Vorschlag oder Idee würde sehr geschätzt werden. Vielen Dank.

Answer 1

Sie kauen über ziemlich viel mit Ihrer Linie der Befragung hier. (Ist da irgendwo eine konkrete Frage versteckt?)

Mit Schichten nehme ich an, Sie meinen physikalische Grenzen, d. H. Anwendung, App/SOA/WCF-Server, Datenschicht, die auf dem SOA-Server lebt, und irgendwo eine Datenbank.

Für die Zukunft zu entwerfen mag eine gute Idee sein, aber stellen Sie sicher, dass dort all diese Schichten irgendwo auf der ganzen Linie gebraucht werden. Im Wesentlichen benötigen Sie keinen WCF/SOA-basierten Ansatz, wenn Sie Ihre Anwendung nicht irgendwann über das Internet veröffentlichen. Ein Web-Frontend kann das gleiche Problem in vielen Fällen lösen.

Ich sage nicht, dass Sie diese Schichten überhaupt nicht brauchen werden, aber Sie könnten nicht. Wenn du es wirklich tust, sind Nähte dein Freund. Sie müssen "Schnittpunkte" machen, wo Sie Ihre Grenzen definieren können. Ich verwende häufig das Repository-Muster, um Datenzugriffsmethoden zu diversifizieren und einfache Objekte (POCO) und Schnittstellen zu verwenden, die über Technologien wie NHibernate erhalten bleiben. Die Verwendung von POCOs macht es VIEL einfacher, diese Objekte zu einem späteren Zeitpunkt entweder einzeln oder als Teil von Nachrichten über die Leitung zu übertragen.

Das Erstellen von Service-Interfaces, die aufgerufen werden, kann Ihre Grenzen festigen. Wenn Sie bereit sind, bereichsübergreifende/physische Grenzen zu verschieben, erstellen Sie einfach Ihre Grenzen in den Service-Implementierungen.

Answer 2

Es klingt sicher wie ein gefährlicher Weg zu gehen - Erstellen der Tabellen zuerst, dann Domäne und schließlich GUI. Ich muss zugeben, ich bin kein Experte für ORM-Experte, aber die generierten Klassen, die ich gesehen habe, sieht mehr wie Datenobjekte als Klassen. Ich würde sagen, Sie brauchen eine andere Schicht, um zu verhindern, dass die Logik in der GUI endet.