Beschränken der Verletzung der Architektur - asp.net MVP

Question

Wenn wir eine definierte Hierarchie in einer Anwendung hatten. Wie schränken wir bei einer 3-Tier-Architektur nachfolgende Entwickler davon ab, die Normen zu verletzen?

Zum Beispiel, im Falle von MVP (nicht asp.net MVC) Architektur, sollte der Moderator immer das Modell binden und anzeigen. Dies hilft beim Schreiben geeigneter Komponententestprogramme. Wir hatten jedoch Fälle, in denen Leute das Modell direkt in die Ansicht importierten und die Funktionen anriefen, die gegen die Normen verstoßen, und daher konnten die Testfälle nicht richtig geschrieben werden.

Gibt es eine Möglichkeit, wie wir einschränken können, welche Klassen von einer Gruppe von Klassen erben dürfen? Ich betrachte verschiedene Möglichkeiten, einschließlich der Annahme eines anderen Entwurfsmusters, aber ein neuer Ansatz sollte den Codewechsel wert sein.

Answer 1

Ich fürchte, das ist nicht möglich. Wir haben dies mit Hilfe von Attributen versucht und es ist uns nicht gelungen. Vielleicht möchten Sie sich auf meine past post on SO beziehen.

Das Beste, was Sie tun können, ist, Ihre Baugruppen mit NDepend zu überprüfen. NDepend zeigt Ihnen das Abhängigkeitsdiagramm von Assemblys in Ihrem Projekt und Sie können die Verstöße sofort verfolgen und reaktiv Maßnahmen ergreifen.

alt text http://www.ndepend.com/Res/NDependBig17.png

Answer 2

Sie wollen ein Menschenproblem mit Software lösen? Bereite dich auf eine Welt des Schmerzes vor!

Der Weg, um das Problem zu lösen, ist sicherzustellen, dass Sie Möglichkeiten haben, mit Menschen zu arbeiten, die Sie nicht mit diesen Arten von Problemen enden .... Pair Programming/Review. Induktion von Menschen, wenn sie das Projekt zum ersten Mal betreten, usw.

Nachdem das gesagt wurde, können Sie Werkzeuge schreiben, die die Software analysieren und nach allgemeinen Problemen suchen. Aber die Leute sind ziemlich kreativ und können alle möglichen Arten bizarrer Dinge finden.

Answer 3

Sobald alles zu Ihrer Zufriedenheit abgeschlossen ist, werden neue Anforderungen eintreffen und Sie müssen die Seite davon durchbrechen.

Die Durchsetzung einer solchen Stringenz auf der Programmierungsebene mit .NET ist fast unmöglich, wenn man bedenkt, dass ein Programmierer durch Reflexion auf alle privaten Mitglieder zugreifen kann.

Tun Sie sich selbst und bevorzugen und planen Sie regelmäßige Code-Überprüfungen, bieten Sie Schulungen an und führen Sie geeignete Schulungen durch. Und wie Sie gesagt haben, wird es schnell offensichtlich werden, wenn Sie keine Unit-Tests dagegen schreiben können.

Answer 4

Es ist fast 3 Jahre her, dass ich diese Frage gestellt. Ich muss sagen, dass ich versucht habe, dies trotz der brillanten Antworten hier zu erforschen. Einige der Lektionen, die ich bisher gelernt habe -

1. Weitere Codegeruch kommen, indem man die Verbraucher auf der Suche (Unit-Tests am besten Platz zu suchen sind, wenn Sie sie haben).

   • Anzahl der Parameter in einem Konstruktor sind eine direkte Angabe der Anzahl der Abhängigkeiten. Zu viele Abhängigkeiten => Klasse macht zu viel.
   • Anzahl der (öffentlichen) Methoden in einer Klasse
   • Aufbau von Unit-Tests wird dies fast immer

2. -Code verschlechtert sich im Laufe der Zeit zu verschenken, es sei denn es eine konzentrierte Anstrengung ist es, technische Schulden zu löschen, und Refactoring . Dies gilt unabhängig von der Sprache.

3. Werkzeuge können nur in gewissem Maße helfen. Aber eine Kombination von Werkzeugen und Tests gibt oft genug Hinweise auf verschiedene Gerüche. Es braucht ein wenig Erfahrung, um sie rechtzeitig zu erfassen, insbesondere um die Bedeutung und Wirkung jedes einzelnen Geruchs zu verstehen.