Come strutturare la logica del livello aziendale (app con logica del livello aziendale molto complessa, calcoli, ecc.)

Question

Come strutturare la logica del livello aziendale (app con logica del livello aziendale molto complessa, calcoli, ecc.)

Naviga le tue risposte

#1 da (2 voti)
#2 da (0 voti)

5

Stiamo sviluppando un'applicazione web .NET che utilizza WebApi . Abbiamo livelli separati:

UI (HTML, CSS, js ecc.)
ApiController - riceve l'input DTO s dall'interfaccia utente e chiama l'endpoint appropriato nel Business Layer (ad esempio, StudentBLL.Add o StudentReportBLL.GetFollowReport )
Business Layer : contiene tutta la logica aziendale; non salva direttamente i dati nel DB, ma chiama il DAL (livello di accesso ai dati).
Data Access Layer (usa Entity Framework per CRUD o, in scenari più complicati, esegue alcune query complicate e così via - non ha logica aziendale).

In aggiunta:

Usiamo "Business Objects" (classi con cui EF lavora; questi oggetti di solito vengono trasformati in tabelle di database nel nostro database relazionale).
Utilizziamo "Visualizza modelli" (utilizzati in Controller e anche in Business Logic).
Usiamo Automapper per mappare Business Objects in View models . La mappatura di solito avviene nel nostro Business Layer.
Abbiamo anche l'iniezione di dipendenza (tutte le classi BLL e DLL hanno interfacce).
Abbiamo servizi aggiuntivi come ExcelReader , OurEmailSender , Workflow ecc. Non abbiamo problemi con questi.

Quindi, finora abbiamo provato a separare tutte le parti logiche.

Ecco la definizione del problema architettonico con cui mi trovo di fronte: È scritto molto sui problemi generali dell'architettura e su come separare i livelli. Ma il problema con cui affronto è che abbiamo un sacco di logica nel nostro Business Layer . Quando abbiamo appena iniziato a sviluppare questa applicazione, il codice ha generato classi Business Layer molto grandi con molti metodi private . Quindi abbiamo iniziato a creare Helpers . Questo ci ha aiutato a pulire un po 'il nostro BusinessLayer, ma abbiamo ancora Helpers molto elevato e qualcosa come " HelpersOfHelpersOfHelpers ". Ovviamente, spesso lo chiamiamo in modo diverso, come "Importer" o "Calculations" o "Exporter", ma comunque, spesso questi sono solo Helpers con alcuni nomi strani.

Puoi dare alcuni indizi su come strutturare Business Logic? Questi potrebbero essere nomi di pattern, alcuni suggerimenti su letture aggiuntive o altro.

architecture business-logic

posta renathy 06.04.2017 - 19:05

fonte

2 risposte

Leggi altre domande sui tag architecture business-logic

trovare le definizioni di token ottimali per la compressione Come gestire il numero di versione nel codice, tra le filiali?

score 2 · Answer 1

Stai ponendo la domanda fondamentale dell'architettura: "Ho molta logica ... come la strutturo?" È difficile rispondere a una domanda così generale in breve poiché numerosi libri hanno scritto su vari aspetti di questo problema.

In breve, probabilmente soffri di "oggetti di Dio", e nomi come "XxxHelper" indicano che le classi non hanno uno scopo ben definito. È molto più facile pensare a un nome significativo se la classe ha uno scopo delimitato e ben definito.

Devi iniziare separando il codice in moduli e classi con scopi chiaramente definiti. Un approccio sarebbe quello di disegnare schizzi o mappe mentali di tutti i compiti e le operazioni nella logica aziendale e cercare di raggrupparli in livelli, sottosistemi, core, servizi, ecc. Sembra che tu abbia già questo principio verso il basso per l'architettura generale, quindi è necessario applicare lo stesso processo di progettazione alla logica aziendale.

I principi fondamentali del design: stratificazione, affettatura, separazione delle preoccupazioni, responsabilità singola, alta coesione-basso-accoppiamento e così via dovrebbero essere applicati a tutti i livelli dell'architettura, non solo al livello più alto.

Se vuoi un approccio più formale, puoi esaminare Domain Driven Design , che descrive un numero di approcci e modelli per strutturare la logica aziendale (o logica di dominio, come viene anche chiamata, che è fondamentalmente la stessa cosa).

score 0 · Answer 2

Un sacco di logica nel tuo livello aziendale è un buon problema, dovrebbe essere lì. Allo stesso modo, i metodi privati non sono necessariamente un grosso problema finché viene seguito un design orientato agli oggetti. Il prossimo passo sarebbe quello di utilizzare principi orientati agli oggetti e modelli di progettazione per astrarre e isolare la logica in unità chiuse. I modelli di fabbrica o di costruzione possono essere utili con l'importazione, e un modo possibile per isolare calcoli complessi è usare il modello di strategia. Le cose importanti di cui preoccuparsi sono molti metodi o classi statici con molti metodi pubblici che non sono collegati tra loro o con metodi quasi identici.