Riferimento circolare tra classi di dati e modelli

Question

Riferimento circolare tra classi di dati e modelli

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

1

Ho il mio progetto C # separato in diversi progetti, quindi ognuno diventerà un .dll dopo.

Ho un progetto per il mio Model e uno per il mio Data . Model è responsabile di Business Logic e rappresentazioni di oggetti di ciò che è nella base dati. Data è responsabile della creazione delle basi dati e delle operazioni generali ORM. Ho anche un progetto Desktop che utilizza sia Model che Data per interagire con l'utente in un programma Windows WPF.

Data ha un riferimento a Model poiché ha bisogno degli oggetti in Model per creare il DB per l'ORM.

Volevo aggiungere Business Logic nei miei modelli in modo che possano essere aggiunti al DB, ad esempio Person.Add() aggiungerà l'istanza dell'oggetto persona al DB, ma Quando aggiungo il progetto Data a Model progetto come riferimento Visual Studio dice che non può essere fatto poiché questo farà un riferimento circolare (che sono d'accordo).

Come tratti di solito questi casi? C'è un modo per mantenere questo tipo di progetti disaccoppiati o è normale unire Data e Model in un progetto?

architecture visual-studio project-structure

posta mFeinstein 16.03.2016 - 01:59

fonte

2 risposte

Leggi altre domande sui tag architecture visual-studio project-structure

Alternative alla classe anonima La comprensione degli elenchi Python è multi-threading o parallela in qualsiasi modo per impostazione predefinita?

score 1 · Answer 1

Il solito modo è avere un terzo eseguibile che prende Data e Model come riferimenti.

Il modo in cui dici che hai bisogno di due diverse DLL è se hai bisogno di mettere ciascuna DLL su una macchina diversa o in diverse applicazioni software. In sostanza, sono necessarie due DLL se la storia della distribuzione per ogni DLL è diversa.

Se non hai questo bisogno, il costo per tenerli separati può superare i benefici, specialmente se verranno utilizzati insieme la maggior parte del tempo.

Inoltre, posso suggerire che Data e Model non sono necessariamente la migliore divisione possibile tra due DLL? Potrebbero esserci alcuni principi organizzativi migliori, come Contabilità e risorse umane, o ServiceLayer e ORM.

score 0 · Answer 2

Questo è un caso comune in cui la dipendenza circolare può essere interrotta utilizzando un'astrazione.

Per prima cosa, non vuoi che singole entità si aggiungano al database. Ciò infrange il principio di responsabilità unica. Per quello dovresti fare una lezione separata. Ma hai ancora un problema che questa classe dipende dal codice all'interno del modulo Data . Questo può essere facilmente risolto introducendo un'astrazione. In Model, si definisce un'interfaccia, che rappresenta un'operazione come Salva, Aggiorna, Elimina, Carica, ecc., E quindi implementa quell'interfaccia in Data modulo. Quindi, quando il modulo dell'applicazione crea i dati, dove è richiesta l'astrazione, passa all'implementazione concreta da Data.

E poiché ci piace dare un nome alle cose, troviamo un nome appropriato per il costrutto sopra. Vediamo .. che dire di Repository ? Bene. Non è perfetto, ma lo farà.