design a più livelli con sito Web e processore di transazioni back-end

Question

Abbiamo un sito Web, in cui le transazioni vengono inserite e inserite attraverso un flusso di lavoro. Seguiremo BLL standard (Business Logic Layer), DTO (Data Transfer Object), DAL (Data Access Layer) ecc. Per un'applicazione a più livelli. Abbiamo la necessità di separare tutto perché alcune transazioni attraverseranno più applicazioni con una diversa logica aziendale.

Abbiamo anche un processore back-end. Gestisce le nostre transazioni una volta completato il flusso di lavoro. Funziona con vari sistemi di terze parti, alcuni dei quali sono instabili o l'interfaccia è instabile, quindi segnala lo stato della transazione. Ogni sito Web avrà la propria versione del processore back-end.

Ora la domanda, con N-Tier, suggerisce un nuovo BLL per ogni applicazione. Con il layout dell'applicazione sopra, si può sostenere che il processore back-end e il sito Web sono un'applicazione che agisce all'unisono o due applicazioni con una diversa logica aziendale. Quale sarebbe il modo ideale per gestirlo? Ha agito come un sistema o due?

Answer 1

Una cosa che ho imparato imparando MVC negli ultimi due anni è la differenza tra ciò che chiamo logica dell'applicazione e logica del dominio. Non mi piace più il termine business logic, perché ha troppi bagagli da tutte le teorie e le pratiche contrastanti che hanno usato quel termine in modo troppo lento.

La logica del dominio è la "tradizionale" logica aziendale, come dovrebbero comportarsi le cose, cosa richiedono (convalida), ecc. La logica dell'applicazione è tutto ciò che è specifico di una determinata presentazione del tuo dominio, IE quando l'utente fa clic su questo pulsante di invio nella tua app Web, quindi viene indirizzato su questa pagina Web qui (si noti che ciò non ha niente a che farebbe con il funzionamento di un'app WinForms o di un processore in background). La logica dell'applicazione dovrebbe risiedere nella tua applicazione. La logica del dominio dovrebbe vivere nel tuo BLL e inferiore ed essere riutilizzabile tra le diverse applicazioni che potrebbero utilizzare la tua "logica aziendale" comune

.

Una specie di risposta generale, ma spero che sia di aiuto.

Answer 2

Potresti considerare di partizionare la funzionalità per riflettere l'organizzazione degli stakeholder. In genere, se si dispone di due gruppi organizzativi distinti, i requisiti di sviluppo e amministrazione sono più facili da gestire se la funzionalità è suddivisa in modo simile. E viceversa.

La maggior parte di noi non impiega molto tempo a scrivere applicazioni che esplorano i confini esterni delle capacità hardware e software.

Answer 3

Se separi bene le tue preoccupazioni, penso che sarai in grado di vederle come la stessa applicazione con un singolo livello di logica aziendale, non ha senso scrivere lo stesso codice due volte. Il trucco consisterà nel forzare la separazione delle preoccupazioni tra le parti dell'interfaccia utente del sito Web e la logica aziendale nella libreria BLL.

Anche le prestazioni saranno un problema, devi assicurarti che l'elaborazione in batch non blocchi il tuo sito Web dall'esecuzione delle attività che deve svolgere a causa delle tue risorse. Questo potrebbe essere un argomento per tenerli più separati, tuttavia, poiché probabilmente condividono comunque un database (o qualche altra risorsa basata su file), ciò potrebbe costituire un problema a prescindere.

Terrei una libreria di logica aziendale comune programmata per le interfacce e completamente separata dalle altre preoccupazioni.

Answer 4

L'ideale "Ideale" il modo per farlo dipende dal progetto attuale e dai vari requisiti del sistema.

Il mio design predefinito è di farlo agire come un'unica app. Ma se ci sono processi più pesanti in corso, mi piace creare un processo di batch in cui i parametri del lavoro richiesto vengono archiviati e seguiti da un processo separato.