J'ai une application qui effectue des calculs complexes pour les membres. Chaque membre peut avoir plusieurs états américains liés à leur profil. Chaque état a des calculs différents pour chaque cours qu'un membre est terminé.
Dès maintenant, j'ai effectué les calculs dans la DB (SQL Server 2008), puis envoyez des données à l'application de la couche d'application où elles peuvent voir leur historique, puis télécharger un certificat pour chaque cours.
J'ai une couche logique d'entreprise mais pas beaucoup de choses se passe là-bas. Je sais que cela a été demandé beaucoup, mais où pensez-vous que je devrais effectuer ces calculs: couche d'entreprise ou base de données? Je vais aller et venir !!
3 Réponses :
Je ferais fondamentalement n'importe quoi dans SQL Server que:
fait beaucoup de sommation, de comptage, de moyennant une moyenne de données et ne renvoie qu'une seule valeur. Il ne sert vraiment pas à transférer de gros volumes de données sur le niveau moyen, juste pour résumer une colonne
fait beaucoup de manipulation à base de ligne / installation; Si vous devez copier, insérer, mettre à jour des lots de données, à nouveau, il n'est vraiment que de faire glisser toutes ces données sur le niveau moyen, puis de l'envoyer tout retour au serveur - faites-le sur le serveur à partir du get Go. En outre: T-SQL est nettement plus rapide dans le traitement des opérations basées sur des installations (telles que le mélange de données autour) que tout dans votre niveau moyen pourraient être
En bref: essayez d'éviter d'envoyer de gros volumes de données à la couche client / centrale / intermédiaire, à moins que vous ne l'iez absolument (par exemple, parce que vous souhaitez télécharger un fichier stocké dans une base de données ou si vous êtes vraiment Une fonction souvent négligée est Je le mettrais dans la couche de logique de niveau moyen / entreprise
S'il nécessitait une vérification logique étendue, une analyse de chaîne, une correspondance de motif, etc. T-SQL suce à ces choses
Si cela nécessitait des choses comme appeler un service Web pour obtenir des données pour valider vos données, ou quelque chose comme celui-ci
Si elle nécessitait plus d'une opération logique d'entreprise (plutôt que des opérations de base de données "atomiques" strictes ")
Mais ce sont des lignes directrices "brutales" - c'est toujours une décision de conception pour chaque cas et je ne crois pas aux règles strictes; Votre kilométrage peut varier, de cas à l'affaire - choisissez donc la seule approche qui fonctionne mieux pour une tâche donnée à portée de main.
Il aide à ne pas avoir de code logique commercial à l'intérieur de la base de données (procédures stockées). Il est beaucoup préférable de l'avoir directement dans l'application afin qu'il convient à l'architecture. Ce code SQL contient votre logique commerciale et il n'y a rien de mal à cela. (Il n'y a rien de mal à avoir un code associé aux données ou à la maintenance dans Sprates).
Si votre couche logique de votre entreprise ne fonctionne pas beaucoup et ne fait que faire passer les données de SQL Server à l'appelant, vous n'en avez pas besoin du tout.
Les procédures stockées peuvent être très utiles - tant qu'ils gèrent les opérations de base de données et ne «masquez» la logique commerciale. Mais pour de nombreuses opérations, une procédure stockée peut être très utile. Je ne voudrais pas seulement les "interdire"
Merci de remercier les gars, fondamentalement une fois que je saisis les données sur le suivi des cours, je renvoie un rapport au député de chaque État, ils sont enregistrés avec tous leurs crédits. Je crois que le DB est le bon endroit pour effectuer ces calculs. C'était un pure vb.net/c# gars qui me demandait si je faisais cela correctement. Bien sûr, il maintient que cela devrait tous être fait à BLL. Chaque situation est différente.
Ne pas appliquer strictement «les meilleures pratiques» comme BLL et DAL sans bon sens. Demandez-les dans votre boîte à outils et utilisez-les quand vous voyez en forme.
La couche logique commerciale n'est pas là pour faire le levage lourd, il est à but de fournir une abstraction avec des entités dans la langue du sujet. Ainsi, la couche d'entreprise peut être utilisée pour fournir une approche partagée et cohérente pour toutes les couches / applications requises pour fonctionner dans cet espace.
sur les choses en ingénieur pour faire un point, l'objectif ultime serait que la couche logique des entreprises soit utilisée dans une organisation pour toutes les applications travaillant dans cet espace. C'est à dire. enveloppé dans un service, etc.
Dans le monde réel des petites applications pour le faire ou cela, la couche logique d'entreprise se sent comme une annexe parfois. L'astuce consiste également à rappeler que tous les cas d'utilisations devraient être mis en œuvre comme des tests contre la couche d'entreprise, vous donnant une autre façon de penser à la manière dont l'interface publique devrait regarder.
Comment la couche logique commerciale obtient-elle que le travail est effectué doit être masqué à partir de ces parties de l'application qui l'appelait.
Il est donc parfaitement acceptable de calculer les données de la manière la plus efficace (c'est-à-dire que ces calculs reçoivent une représentation appropriée dans la couche logique des entreprises.
Je ferais toujours des calculs dans la base de données, si Votre calcul devra retourner Beaucoup de données au niveau moyen, juste pour avoir par exemple. un
somme calculé. Pourquoi déranger toutes ces données autour ?? La base de données est bien équipée pour résumer certaines valeurs et renvoyer un seul résultat - beaucoup plus efficace! Donc, chaque fois que vous devez faire beaucoup - mais retourne peu - faites-le sur le serveur.Je suis d'accord avec @marc_s SQL Server est conçu pour traiter les données rapidement et plus efficacement.