.net code de développement structure -Contrôleurs, Services, Dépôts et Contextes

Question

En tant que nouveau développeur, je suis très confus en nommant et conventions structurelles pour le développement de code C# en utilisant les meilleures pratiques. J'apprécie qu'il soit peut-être applicable à chaque domaine pour lequel je suis en train de développer mais j'ai vu le code de nombreux projets open source différents et il semble y avoir un thème commun. Les projets réussis ont une structure bien pensée pour la maintenance et l'extensibilité. Les termes context, service, repository et controllers sont souvent utilisés et je me demandais s'ils étaient ouverts à l'interprétation ou s'il existait un consensus ou une convention sur quoi, où et comment ils sont utilisés.

Dans une plateforme de commerce électronique, j'ai vu des services de commande, des contextes de commandes, des référentiels clients et des contrôleurs de produits par exemple. Que devraient-ils faire en fonction de ces noms? Un contrôleur fait-il quelque chose de différent d'un service? Quand devriez-vous utiliser un contexte? Y a-t-il une convention pour les espaces de noms? Il est ahurissant quand vous essayez de pousser d'une cuillère nourris développeur newbie et essayer de passer à autre chose.

De quels logiciels/outils devrais-je vraiment tenir compte pour développer un code de qualité? Test Unitaire, Intégration Continue, Resharper, Outils de Mocking, Conteneurs DOI, nHibernate.

Je ne suis pas vraiment au courant des blogs/livres qui m'aideront à devenir un développeur web compétent dans quelqu'un qui peut développer un code extensible, de qualité et testable. Il y a de grandes lacunes dans les hypothèses des auteurs. Vous êtes un débutant ou un architecte logiciel.

Je veux pousser d'être un développeur junior avec un but à long terme d'être un architecte logiciel. Je réalise que tout est une question de modèles et de pratiques, mais où sont les matériels de formation? Je travaille seul, donc je n'ai pas l'opportunité d'apprendre des autres.

Merci

Answer 1

Pour les tests unitaires, il y a NUnit. Pour l'intégration continue il y a CruiseControl.net Pour moquer il y a Moq, ou RhinoMocks, personnellement, je trouve Moq plus simple et plus facile à apprendre. Pour DI il y a Ninject, et Structuremap et quelques autres, je préfère StructureMap. Ce sont ceux que j'ai utilisés et généralement il y a plus d'une option.

Si vous voulez un bon livre qui vous entrer dans ASP.NET MVC, modèles de conception courants comme le modèle du référentiel, et dans le développement du code testable Je recommande Pro ASP.NET MVC 2

En ce qui concerne les conventions de nommage dont vous parlez, ce sont des conventions communes de Domain Driven Design, beaucoup de gens utilisent ou utilisent partiellement DDD dans .NET, vous pouvez obtenir plus d'informations here.

Answer 2

Je ne pense pas qu'il existe une solution parfaite pour votre réponse. Je me suis aussi confus. Mais avec mes expériences dans le travail et l'école, j'ai fait mes propres règles. Peut-être vous donnera une idée de ce que vous avez demandé. Je suppose que vous connaissez déjà le modèle de conception MVC. Où Model est sur le point de gérer la logique et la base de données de votre entreprise. La vue est ce que vous voulez voir à l'écran. Et le contrôleur doit répondre à la demande des utilisateurs et décider quelle vue et quel modèle doivent être chargés.

J'ai généralement organisé mon modèle en créant un dossier (espace de noms) pour y parvenir.Voici mon modèle:

• Repository: ne le fera requête, insérer, mettre à jour et supprimer une seule table (interface et met en application).
• Services: la combinaison de les tables basées sur le référentiel, se connecter et se déconnecter, et d'autres qui ne sont pas liés à l'accès à la base de données.
• Classes: sont l'objet déclaré.
• utils: fonctions statiques Dévier à partir du référentiel et peut être appelé par View.

Peut-être que vous pouvez partager les vôtres !!