it-swarm.com.de

Warum legt jeder Controller in einem Ordner und Ansichten in einem anderen ab?

Ich mache mich bereit, die Biegung von asp in ein mvc-Framework, asp.net mvc oder nancy zu nehmen. Wo immer ich hingehe, sehe ich Ordner für Controller/Module und Ordner für Ansichten. Ist dies nur ein pawlowscher Reflex, Dinge nach Typ aufzuräumen, oder wirkt eine tiefere Weisheit? Ich habe ein kleines Proof-of-Concept-Projekt, in dem ich die Dateien, die ich wahrscheinlich zusammen öffne, zusammen speichere, ein beträchtlicher Komfort. Da sich diese Dateien wahrscheinlich auch gegenseitig aufrufen, können sie dies mit kürzeren, weniger spröden, relativen Links tun. Dieses Muster wird von mvc in Frage gestellt, da der Ordnerpfad nicht mehr automatisch dem URL-Pfad entspricht und in asp.net mvc die Projektvorlagen und das Routing die Ansichten\controller\schism erzwingen.

Diese Microsoft-Seite führt in das Konzept der Bereiche ein. Es kann als ein Eingeständnis gelesen werden, wie unhandlich große Apps aufgrund dieser künstlichen Trennung werden.

Die Leute werden "Trennung von Bedenken" ablehnen, aber die Trennung von Bedenken wird bereits durch separate Quelldateien erreicht. Es scheint mir keinen konkreten Vorteil zu haben, diese eng gekoppelten Quelldateien an entgegengesetzte Enden der Ordnerstruktur zu senden?

Kämpft sonst noch jemand dagegen an? Irgendwelche Tipps?

41
bbsimonbb

Ich würde gerne sagen, es ist Frachtkultprogrammierung , aber es gibt technische Gründe für diese Struktur. Asp.Net MVC verfolgte für fast alles eine Konvention über den Konfigurationsansatz. Standardmäßig durchsucht die Razor View Engine das Verzeichnis Views, um festzustellen, welche Ansicht vom Controller zurückgegeben werden soll. Es gibt jedoch einige Hacks , um eine andere Projektstruktur zu erhalten, und Microsoft bietet sogar eine MVC-Funktion namens Areas an, mit der wir eine vernünftigere Projektstruktur erstellen können. Sie können auch implementieren Sie Ihre eigene Ansichts-Engine , um anzugeben, wo nach Ansichten gesucht werden soll.

Warum sage ich, dass es sich um Frachtkultprogramm handelt und dass Sie diesbezüglich Recht haben? Onkel Bob hat mich überzeugt dass die Verzeichnisstruktur des Projekts mir nicht sagen sollte, dass es sich um eine MVC-Anwendung handelt. Es sollte mir sagen, dass es sich um eine Ladenfront oder ein Freizeitanforderungssystem handelt oder was auch immer. Die Struktur und Architektur auf hoher Ebene sollte uns sagen, was dieses Ding ist, nicht wie es wurde umgesetzt.

Kurz gesagt, ich glaube, Sie haben Recht damit, aber jede andere Verzeichnisstruktur würde einfach gegen das Framework kämpfen und mir vertrauen, wenn ich sage, dass Sie nicht versuchen möchten, das Asp.Net MVC-Framework dazu zu bringen, etwas zu tun, was es nicht war nicht dafür gedacht. Schade, dass es nicht wirklich konfigurierbarer ist.


Um schnell auf architektonische Bedenken einzugehen, glaube ich immer noch, dass die Geschäftsmodelle (Geschäft, nicht Ansicht) und die DAL in einem separaten Projekt/einer separaten Bibliothek leben sollten, die von Ihrer MVC-App aufgerufen wird.

Es ist nur so, dass der Controller wirklich sehr eng mit der Ansicht verbunden ist und wahrscheinlich zusammen modifiziert wird. Wir alle sollten uns den Unterschied zwischen der Kopplung über Abhängigkeit und der logischen Kopplung merken. Nur weil die Abhängigkeiten des Codes entkoppelt wurden, ist er nicht weniger logisch gekoppelt.

43
RubberDuck

Was auch immer der Grund sein mag, dies ist eine schlechte Praxis. Es ist sehr anti-OO, da Pakete oder Ordner (wie auch immer Sie sie nennen möchten) schwache Abhängigkeiten aufweisen sollten. Klassen (oder Dateien) in ihnen sollten starke Abhängigkeiten aufweisen.

Indem Sie alle Ansichten in einen Ordner und alle Controller in einen anderen Ordner werfen, erstellen Sie zwei Pakete mit sehr sehr enger Kopplung. Dies widerspricht dem Prinzip schwacher Abhängigkeiten zwischen Paketen.

Eine Ansicht und ein Controller sind zwei Hälften eines Ganzen und sollten zueinander gehören. Sie hätten nicht einen Schrank für Socken auf der linken Seite und einen anderen für Socken auf der rechten Seite.

9
Oliver Watkins

Um Ihre Frage zu beantworten: "Warum alle ...?" Frage: Hier sind einige mögliche Gründe, obwohl ich nicht ganz sicher bin, welche Kombination von ihnen eine echte Ursache ist, da es sich tatsächlich um eine subjektive Frage handelt

  • Replizieren der logischen Architektur (Modell, Ansicht, Controller) mit einer passenden Ordner- und Namespace-Struktur

  • Aus Konvention und Bequemlichkeit folgen Sie der ASP.net MVC-Projektvorlage

  • Nach Namespace gruppieren, da Controllers/ Ordner führt zu einem .Controllers Namespace

  • Könnte einige Szenarien in DI/IoC aktivieren, in denen Controller-Klassen nur von einem Namespace abgefragt/gescannt werden, der 'Controller' enthält/endet - dies könnte falsch sein)

  • Damit T4-Vorlagen gescannt und Modelle und Controller gerüstet werden können, um Ansichten zu generieren

Sie können jederzeit Ihre eigene Konvention erstellen und befolgen, wenn dies für Ihr Projekt sinnvoll ist und niemand Sie aufhalten kann/wird. Beachten Sie jedoch, dass die Standardkonvention, die jedem bekannt ist, möglicherweise die bessere Wahl ist, wenn Sie in einem großen Projekt und/oder einem großen Team arbeiten (jedoch nicht unbedingt die richtige!).

Wenn Ihre Konvention leichter zu befolgen ist und die Produktivität nicht beeinträchtigt, dann tun Sie es auf jeden Fall! und vielleicht sogar ein oder zwei Blog-Posts darüber schreiben, um mit der Entwickler-Community in Kontakt zu treten und Feedback zu erhalten

7
Bishoy

Ein Grund, Ansichten und Controller in separaten Verzeichnissen zu speichern, besteht darin, dass Front-End- und Back-End-Entwickler an einem Projekt arbeiten. Sie können verhindern, dass Front-End-Entwickler auf Back-End-Code zugreifen (z. B. um die PCI-Konformität zu unterstützen und den Zugriff auf vertraulichen Code einzuschränken).

Ein weiterer Grund ist, es einfacher zu machen, "Themen" zu haben und alle der Vorlagen auszutauschen, indem Sie den Ansichtspfad geringfügig ändern.

Ein dritter Grund ist ein einfaches Verzeichnismuster beim Angeben von Ansichten im MVC-Framework. Es ist einfacher, das Unterverzeichnis und die Datei anzugeben, als einen großen langen Pfad zu jeder Ansicht.

Die einzige "enge Kupplung" sollte sein:

  1. Vom Controller in die Ansicht gesendete Variablen.
  2. Formularfelder oder Aktionen in der Ansicht, die an die Steuerung zurückgesendet werden.

Ich verwende einen generischen Controller und versuche, Variablennamen in der generischen Ansicht beizubehalten, sodass viele Ansichten denselben Controller und viele Controller dieselbe Ansicht verwenden können. Aus diesem Grund ziehe ich es vor, die Ansichten völlig getrennt zu halten. Im Modell können Sie jedes "Ding" in Ihrer Anwendung unterscheiden - es können Objekte mit einer Liste von Eigenschaften und Methoden sein, um auf diese Eigenschaften zuzugreifen/sie zu ändern.

Bei eng gekoppeltem Code besteht ein Ansatz, der für Sie funktionieren könnte, darin, alle Dateien, die Teil eines Pakets oder "Moduls" sind, in einem Verzeichnis mit Namespace zusammenzuhalten. Anschließend können Sie Ihre Rohvorlagen mithilfe eines Skripts in das Hauptverzeichnis "views" kopieren oder "kompilieren". Zum Beispiel:


    lib/my-namespace/my-package/
        -> controllers/
        -> models/
        -> views/
            -> theme/
               -> template-name1
    app/compiled_views/theme/
        -> url/path/template-name1


Wenn Sie die Struktur eines vorhandenen Themas ändern möchten, müssen Sie leider mehr Paketverzeichnisse ein- und ausweben, um die Ansichten zu aktualisieren.

Bedenken Sie, dass Ansichten nur eine Möglichkeit sind, Daten zu formatieren, egal ob es sich um JSON, XML, CSV oder HTML handelt. Dies ist besonders hilfreich, wenn Ihre Anwendung auch als API fungieren soll. Versuchen Sie, die Ansicht mithilfe generischer Variablennamen von den Daten zu entkoppeln, damit Sie für viele Controller oder Modelle dieselbe Vorlage verwenden können (oder verwenden Sie Includes, um die Menge an Code zu minimieren, die Sie warten müssen).

2
Frank Forte

Denken Sie daran, es ist die von Microsoft empfohlene Methode , um die Controller und Ansichten in verschiedenen Ordnern zu speichern, sodass viele der empfohlenen Struktur folgen würden.

  1. Ein Grund könnte sein, dass Controller immer keine Eins-zu-Eins-Beziehung zu Ansichten haben, insbesondere können die Teilansichten von Controllern gemeinsam genutzt werden.
  2. Ein weiterer Grund könnte sein, dass Sie, wenn Ihr Projekt wächst, Controller und Komponententests auf andere Projekte übertragen möchten. Es ist jedoch ziemlich schwierig, dasselbe für Ansichten zu tun, und Ansichten/js/css gehören zusammen, da sie sich gegenseitig referenzieren.

Trotzdem gibt es viele Beiträge darüber, wie man es auf seine Weise macht, wie zum Beispiel this .

1

Das macht nicht unbedingt jeder. Zum Beispiel hat Pythons Django Framework hat das Konzept einer App, bei der Submodule Ihrer Anwendung in ihren eigenen Verzeichnissen mit ihren eigenen Modellen und Ansichten und Vorlagen leben (Ansichten sind was Django ruft im Wesentlichen Controller auf. Ich bevorzuge diese Vorgehensweise, da dies bedeutet, dass ich eine "App" einfach verpacken und projektübergreifend wiederverwenden kann, indem ich sie einfach in die App-Liste in meinen Projekteinstellungen aufnehme Es ist auch einfacher herauszufinden, wo sich verschiedene Teile befinden. Wenn ich mir die Datei urls.py ansehe und etwas wie url(r'^users/', include('my_site.users.urls')) sehe, weiß ich, dass das Modul my_site.users enthält den gesamten Code, der Benutzer behandelt. Ich kann mir die Module ansehen my_site.users.views und my_site.users.models wenn ich sehen möchte, wie Benutzer erstellt und authentifiziert werden. Ich weiß, dass alle meine Routen in my_site.users.url.

Auch wenn es allgemein genug ist, kann ich dieses Modul wahrscheinlich auf anderen Websites verwenden, indem ich einfach die Konfiguration ändere oder es als Bibliothek verpacke und als OSS veröffentliche.

1
Pavel Penev

Für die Aufzeichnung

Warum sage ich, dass es sich um Frachtkultprogramm handelt und dass Sie diesbezüglich Recht haben? Onkel Bob hat mich überzeugt, dass die Verzeichnisstruktur des Projekts mir nicht sagen sollte, dass es sich um eine MVC-Anwendung handelt. Es sollte mir sagen, dass es sich um eine Ladenfront oder ein Freizeitanforderungssystem handelt oder was auch immer. Die Struktur und Architektur auf hoher Ebene sollte uns sagen, was dieses Ding ist, nicht wie es implementiert wurde.

Frage: Wer hat Zugriff auf den Code?. Programmierer. Interessieren sich Endbenutzer für den Code? Und was ein Programmierer macht, Code. Oder genauer gesagt, Klassen basierend auf Typen (Controller, Service, Modell usw.). Es ist also sinnvoll und es ist einfach, einen Code zu debuggen, wenn Sie einen Code finden können, der auf dem Codetyp basiert, anstatt auf dem Verhalten des Codes. Nehmen wir zum Beispiel ein Teamprojekt an, eines ist verantwortlich für den Controller, ein anderes für das Modell, ein anderes für das Dao und ein anderes für die Ansicht. Es ist einfach, das Projekt in Teile zu trennen. Ein guter Code ist ein Code, der leicht zu debuggen ist, kein Syntaxzuckercode. Onkel Bob liegt wieder falsch.

Der Versuch, das Verhalten des Projekts (eine Ladenfront) nachzuahmen, ist Frachtkult.

0
magallanes