Question

Est-il « acceptable » d'avoir un ASP.Net 2.0 application sans le BLL (Business Logic Layer) comme suit ?

  1. Stockage de données SQL Server et procédures stockées
  2. Couche de liaison de données (adaptateurs de table fortement typés) se connectant aux processus stockés
  3. Pages ASPX de la couche de présentation avec code derrière et ObjectDataSource pour une connexion directe à la DLL

Un BLL est-il toujours préférable, même si la logique métier est entièrement validable dans le code sous-jacent de la présentation ?Quels sont les inconvénients potentiels de ne pas utiliser de BLL ?

Pas de solution correcte

Autres conseils

C'est acceptable tant que vous comprenez les conséquences.La principale raison pour laquelle vous auriez une BLL est de réutiliser cette logique ailleurs dans votre application.

Si vous avez toute cette logique de validation dans le code de présentation, vous compliquez vraiment la réutilisation ailleurs dans votre application.

Comme tout le reste, c'est environnemental et dépend de l'utilisation du système.La question que vous devez vous poser est la suivante :

  1. Est-ce que cela sera activement développé
  2. Est-ce que cela va être utilisé pendant de nombreuses années et étendu
  3. L'expansion de l'application est-elle inconnue et donc infinie

En réalité, c'est une question de paresse.Combien de temps souhaitez-vous consacrer à retravailler le système à partir de l’interface utilisateur ?Parce que ne pas avoir de couche métier signifie la duplication des règles dans votre interface utilisateur sur de nombreuses pages.

Là encore, s'il s'agit d'une preuve de concept, d'une courte démo ou d'un projet de classe.Choisissez la solution de facilité.

Acceptable?Cela dépend à qui vous demandez et quelles sont vos exigences.Cette application est-elle une application interne unique utilisée par vous et quelques autres personnes ?Peut-être que c'est suffisant.S'il s'agit d'une application d'entreprise prête pour la production, qui se développera et sera maintenue au fil des années, vous souhaiterez probablement investir davantage d'efforts dès le départ pour créer une application maintenable.

La séparation des préoccupations est une technique de conception clé pour créer des applications maintenables.En mélangeant la logique de présentation, la logique métier et l'accès aux données, vous pouvez vous retrouver avec une architecture d'application très fragile et difficile à modifier.

Ça dépend.Si votre logique métier se trouve dans vos événements de clic et vos chargements de pages, ce n'est PAS acceptable.

Il semble que votre logique métier se trouve quelque part dans le DAL (par exemple, les procédures stockées, etc.), tant que vous êtes cohérent, tout va bien.Tant que vous êtes très, très sûr que vos clients le feront toujours Si vous utilisez SQL Server, cette approche n'est pas un problème.

Je connais un collègue qui a tous sa logique métier dans les procédures stockées que ses vues sont principalement des clients légers vers les backends de bases de données :il a connu un immense succès avec le produit qu'il vend.Mais c’est uniquement parce qu’il est très cohérent avec cela.

Si l'application est générale, la couche de logique métier peut également être utilisée dans d'autres applications complètes.Par exemple, j'utilise normalement mes classes BLL liées au CMS dans d'autres applications.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top