Come separare in modo pulito diverse parti di un'applicazione software?

Question

Come separare in modo pulito diverse parti di un'applicazione software?

#1 da (5 voti)
#2 da (4 voti)

8

Sto progettando una nuova applicazione che si occupa di molte logiche di business.

Per evitare il solito intreccio tra diversi livelli applicativi che spesso si insinuano in tali sistemi nel tempo, voglio attuare una netta separazione delle preoccupazioni fin dall'inizio. Parlando in generale, voglio separare:

livello di presentazione
strato logico aziendale
archiviazione dati e livello di persistenza

La domanda con cui sto lottando di più è come implementare effettivamente il comportamento ai bordi in modo pulito, in particolare tra l'azienda e il livello dati. Ho visto troppe applicazioni in cui il livello dati consegna gli oggetti ORM al livello principale, accoppiando in modo efficace la logica aziendale all'ORM.

Dovrei convertire gli oggetti ORM in un formato serializzato (JSON?) e poi deserializzare quello nel livello aziendale in una struttura dati interna a quel livello? Non è un sacco di spese generali?

Come implementa in modo pulito la separazione delle preoccupazioni per le applicazioni di medie dimensioni? Qualche consiglio?

design separation-of-concerns modularization

posta B.M. 15.03.2017 - 16:33

fonte

2 risposte

Leggi altre domande sui tag design separation-of-concerns modularization

Qual è una buona tecnica di stima per le stime iniziali di alto livello? Gestione del codice Firma in un ambiente controllato sorgente

score 5 · Answer 1

C'è sempre qualcosa di un accoppiamento logico tra la business logic e il database. I tuoi sforzi dovrebbero concentrarsi sulla prevenzione di un accoppiamento fisico .

Ad esempio, prendi la regola aziendale di base che ogni utente deve avere un ID utente univoco. Puoi provare a far rispettare questa regola nel livello aziendale, ma ci sarà sempre uno scenario in cui più utenti possono provare lo stesso ID utente allo stesso tempo e l'unico posto in cui puoi verificare l'univocità e riservare un ID utente in un la via atomica è nel database.

Ora, il livello aziendale non dovrebbe aver bisogno di conoscere il nome della tabella o della colonna, o anche che gli utenti siano memorizzati in un database (potrebbero, per esempio, essere archiviati in Active Directory, invece, per un'applicazione intranet) . Solo il livello di accesso ai dati dovrebbe saperlo. Ma passare un sacco di tempo a disconnettere lo schema dalle regole aziendali è probabilmente uno spreco di energie.

score 4 · Answer 2

Assicurati che gli oggetti del tuo modello di business siano nella loro stessa libreria che non fa riferimento a nessun client ORM o database.

Utilizza il modello di repository e solo le interfacce di riferimento ai repository nel tuo codice principale.

Avere una libreria di repository concreta completamente separata specifica per il datalayer che fa riferimento alla libreria di interfacce, alla libreria dei modelli di business e al client del database.