Conception multiniveau avec site Web et processeur de transaction dorsal

Question

Nous avons un site Web sur lequel les transactions sont entrées et traitées dans un flux de travail. Nous allons suivre les normes BLL (couche de logique métier), DTO (objet de transfert de données), DAL (couche d'accès de données), etc. pour une application à plusieurs niveaux. Nous avons besoin de tout séparer, car certaines transactions traverseront plusieurs applications avec une logique métier différente.

Nous avons également un processeur backend. Il gère nos transactions une fois le flux de travail terminé. Il fonctionne avec divers systèmes tiers, dont certains sont instables, ou l'interface entre eux est instable, puis indique le statut de la transaction. Chaque site Web aura sa propre version du processeur principal.

Maintenant la question, avec N-Tier, ils suggèrent un nouveau BLL pour chaque application. Avec la présentation de l'application ci-dessus, on peut affirmer que le processeur principal et le site Web sont une application agissant à l'unisson ou deux applications avec une logique métier différente. Quel serait le moyen idéal pour gérer cela? Avez-vous agi comme un système, ou deux?

Answer 1

Au cours des deux dernières années, j’ai pris conscience de l’apprentissage de MVC, c’est la différence entre ce que j’appelle la logique d’application et la logique de domaine. Je n’aime plus le terme «logique commerciale», car il contient trop de bagages de la part de toutes les théories et pratiques contradictoires qui ont utilisé ce terme de manière trop vague.

La logique de domaine est "traditionnelle". la logique métier, la manière dont les choses sont censées agir, ce dont elles ont besoin (validation), etc. La logique d'application désigne tout ce qui est spécifique à une présentation donnée de votre domaine. IE lorsque l'utilisateur clique sur ce bouton d'envoi dans votre application Web, il est ensuite dirigé sur cette page Web ici (notez que cela n'a rien à voir avec le fonctionnement d'une application WinForms ou d'un processeur d'arrière-plan). La logique d'application devrait vivre dans votre application. La logique de domaine doit résider dans votre BLL et dans sa version inférieure, et doit être réutilisable dans les différentes applications pouvant utiliser votre "logique métier" commune.

Une sorte de réponse générale, mais j'espère que cela aidera.

Answer 2

Vous pouvez envisager de partitionner la fonctionnalité pour refléter l'organisation des parties prenantes. Généralement, si vous avez deux groupes d'organisation distincts, les exigences de développement et d'administration sont plus faciles à gérer si les fonctionnalités sont partagées de la même manière. Et vice versa.

La plupart d'entre nous ne consacrons pas beaucoup de temps à écrire des applications qui explorent les limites extérieures des capacités matérielles et logicielles.

Answer 3

Si vous séparez bien vos préoccupations, je pense que vous pourrez les voir comme la même application avec une seule couche de logique applicative. Inutile d’écrire le même code deux fois. L'astuce consiste à forcer la séparation des problèmes entre les parties de l'interface utilisateur du site Web et la logique métier de votre bibliothèque BLL.

Les performances vont également poser problème, vous devez vous assurer que votre traitement par lots n’empêche pas votre site Web d’accomplir les tâches qu’il doit exécuter en raison de vos ressources. Cela peut être un argument pour les garder plus séparés, mais comme ils partagent probablement une base de données (ou une autre ressource basée sur un fichier), cela peut être un problème malgré tout.

Je conserverais une bibliothèque de logique commerciale commune programmée pour les interfaces et entièrement séparée de vos autres préoccupations.

Answer 4

Le " Idéal " La manière de le faire dépend du projet et des diverses exigences du système.

Ma conception par défaut consiste à le faire agir comme une application. Mais s’il ya davantage de processus lourds en cours, j’aime créer un processus de traitement par lots dans lequel les paramètres du travail demandé sont stockés et traités par un processus séparé.