Cadres d'application - Acheter, construire ou assimiler?

Question

J'étais curieux de savoir ce que font les autres magasins en ce qui concerne les frameworks d'application de base? Je considère un cadre d'application comme étant capable de fournir des fonctionnalités supplémentaires ou étendues pour améliorer la qualité des applications construites à partir de celui-ci.

Il existe une variété de cadres de la boîte, tels que Spring (ou Spring.NET), etc. Je trouve que le plus gros problème avec ceux-ci étant qu'ils ne sont pas à la carte. Fondamentalement, ils ont trop de fonctionnalités et à moins que chaque élément de cette fonctionnalité soit la meilleure implémentation disponible, il est fort probable que vous finirez par utiliser un patchwork de plusieurs frameworks pour accomplir ces tâches - provoquant une confusion et une confusion. Cela vaut pour les systèmes libres et commerciaux, à mon avis.

Bien sûr, l'écriture réinvente largement la roue. Je ne pense pas que ce soit sans mérite, car il fournit l'option la plus personnalisable. Cependant, certaines choses sont trop importantes pour être développées et semblent être mal mises en œuvre ou pas du tout mises en œuvre dans ce cas en raison de l'hésitation à s'engager dans les coûts initiaux de développement.

Il existe une grande variété de projets open source qui traitent également des parties individuelles d'un framework d'application potentiel. Ceux-ci peuvent être adoptés ou assimilés (évidemment en fonction des accords de licence) pour aider à encadrer dans un cadre global de diverses sources.

Nous avons abordé la situation en examinant certaines des préoccupations majeures de nos applications dans l'ensemble de l'entreprise et avons dressé une liste de problèmes transversaux valides et de problèmes de mise en œuvre récurrents. Au final, nous sommes arrivés à une solution hybride partiellement open source, basée en partie sur des options open source existantes, et partiellement développée sur mesure.

Quelques exemples de choses qui sont dans notre cadre:

• fournisseurs journalisation exception et des événements. Un moyen simple et uniforme par lequel chaque application peut enregistrer des exceptions et des événements de manière identique avec un effort de codage minimal. En sortie de boîte, il peut se connecter à un serveur SQL, à un fichier texte, à un visualiseur d'événements, etc. Il contient également des points d'extensibilité permettant de se connecter à d'autres sources.
• Application de l'affectation des variables. Classe générique qui expose les méthodes d'extension en fonction du type d'objet, en utilisant une syntaxe inspirée de JUnit. Par exemple, pour déterminer si myObject n'est pas null, nous pouvons faire un simple Enforce.That (myObject) .IsNotNull(); ou déterminez s'il s'agit d'un type spécifique en faisant un simple Enforce.That (myObject) .IsOfType (typeof (Hashtable)); Les échecs d'application soulèvent l'exception appropriée, à la fois en réduisant la quantité de code et en assurant une cohérence dans la mise en œuvre.
• Auxiliaires de tests unitaires. Une série de classes, basée sur la réflexion, qui permet de tester automatiquement les classes et leurs propriétés. (Inspiré par Automatic Class Tester de CodePlex) mais écrit à partir de la base. Aide à simplifier la création de tests unitaires pour les tâches qui sont traditionnellement difficiles ou longues à tester.

Nous avons également carrément adopté d'autres fonctionnalités, telles quelles. Par exemple, nous utilisons PostSharp pour AOP, moq pour le moqueur et autofaq pour DI.

Vous vous demandez simplement ce que d'autres personnes ont pu faire et quelles sont les adresses de votre framework que vous n'avez pas trouvé d'outil satisfaisant? En ce qui concerne notre expérience, nous récoltons sans aucun doute les avantages du nouveau cadre et nous sommes satisfaits de l'approche que nous avons adoptée.

Answer 1

Notre approche a consisté à consacrer toute une équipe d'architectes (à savoir « Technical Architects ») pour:

• soit l'adaptation existante cadre open-source, dans certains cas, les encapsuler dans une API en interne afin de être en mesure de changer de cadre en cas de besoin
• ou de créer un nouveau cadre basé sur les besoins spécifiques trouvé plusieurs équipes pour plusieurs projets.

Quelle que soit l'approche, les cadres doivent être très bien documenté (au moins avec un complet public API), et leur libération doivent être bien annoncés:
Puisque toutes les équipes en fonction de leur travail sur ces cadres, ils besoin de mettre à jour leurs versions de framework le plus rapidement possible, afin de construire leurs propres livraisons.

Answer 2

Mon conseil simple est que vous utilisez un cadre qui convient à vos besoins.Bien sûr, pour ce faire, vous devez expérimenter et savoir à l'avance ce que vous cherchez. Même si le cadre vient avec beaucoup plus que ce dont vous avez besoin, quel en est le coût? Pour le problème moyen, le coût n'est que de quelques Mbs supplémentaires dans un pot, ce qui est OK pour la plupart des projets. En fin de compte, vous devriez choisir un framework qui fait le bon travail, de sorte que votre objectif soit de fournir une valeur utilisateur et de faciliter la maintenance du développeur. Bien sûr, il n'y a pas un seul cadre qui aborde les problèmes de tout le monde, mais il y a des cadres qui correspondent à ce qu'ils visent. Tout est une question d'aller avec le meilleur compromis.