application web couche de données dis/avantages

Question

Je m'interroge sur les avantages à long terme (le cas échéant) de superposer mon application Web en séparant ma logique métier et les données de mes formulaires Web. (c'est-à-dire un formulaire, une logique métier, des données qui ne se trouvent pas dans le même fichier, mais chacun dans sa propre classe dans un autre dossier seul ou combiné avec d'autres classes similaires). J'aime rendre tout aussi modulaire que possible et pour le faire efficacement, il semble que tout le code soit conservé dans un seul fichier - dans le formulaire Web, l'organisation et la réutilisation sont beaucoup plus faciles. Certaines fonctions sont utilisées sur le site, comme la gestion des connexions qui se trouvent dans leurs propres classes et fichiers. Je suis assez nouveau à C#, désolé si je suis en train de bousiller la terminologie.

Merci

Answer 1

La séparation de code dans des couches apporte des avantages au-delà le langage C#.

Si votre code d'accès aux données est conservé dans une couche distincte, il sera facile de l'ajuster pour fonctionner avec une base de données différente. Le code spécifique à la base de données sera encapsulé dans cette couche tandis que les clients travailleront avec des interfaces agnostiques de base de données. Par conséquent, les modifications apportées ici n'affecteront pas l'implémentation de la couche de gestion.

Si votre logique métier est conservée au même endroit, vous pourrez offrir ses services à d'autres applications, par exemple, pour répondre aux demandes effectuées via les services Web.

Si votre code est propre et bien structuré, les efforts de maintenance seront maintenus plus bas. Chaque fois que vous avez besoin de changer quelque chose, vous saurez où trouver le code responsable, quoi changer et comment assurer le changement n'affectera pas le reste du code. Comme pour ASP.NET, ne pas suivre la séparation des préoccupations a provoqué la transformation de nombreux projets en un code de code géant - le code de présentation prend des décisions d'affaires, code-behind parle directement à la base de données s'écrit à partir de plusieurs endroits, le flux de données suit plusieurs chemins qui sont difficiles à tracer, les changements dans un chemin non introduit à l'ensemble briseront l'intégrité et causeront la corruption des données => Résultat? Code boîte noire presque impossible à maintenir où tout changement nécessite de plus en plus d'efforts jusqu'à ce qu'il se bloque - le projet est "fini". Faillite technique

Answer 2

Nous couche généralement notre application comme suit (chacune de la couche est dans un projet distinct de la solution et par conséquent dans une dll séparée: Ce que je toujours aller (premier) est d'avoir une application en couches

• couche présentation (JUST logique interface utilisateur et la liaison de données)
• couche d'interface à la couche métier (définissant les contrats pour l'accès à la BL)
• de mise en œuvre de la couche d'affaires (la logique réelle , des données validation etc ...)
• Interface couche à l'accès aux données couche (définition des contrats pour accéder au DAL)
• d'accès aux données couche mise en œuvre

Vous pouvez alors utiliser une usine pour récupérer les objets correspondants. Je voudrais jeter un oeil à une bibliothèque, éventuellement en utilisant l'injection de dépendance comme Spring.Net ou Microsoft Unity à partir des modèles et des pratiques MS.

Les avantages sont les suivants:

séparation
• de la logique où il appartient à
• aucune logique métier dans l'interface utilisateur (les développeurs doivent prêter attention à ce sujet)
• toutes vos applications se ressemblent même et par conséquent les développeurs connaissant cette architecture sauront immédiatement où chercher la logique correspondante
• DAL échangeable. Les interfaces définissent les contrats d'accès à la couche correspondante.
• Les tests unitaires deviennent plus faciles, en se concentrant uniquement sur la logique BL et DAL
• Votre application peut avoir de nombreux points d'entrée (interface Web, client Winforms, service Web). Tous peuvent référencer la même logique métier (et DAL).
• ...

ne pouvait pas vivre sans cela ..