Oggetto dominio framework entità come oggetto business

Question

Oggetto dominio framework entità come oggetto business

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

5

Se non mi occupo di test delle unità e di accesso ai miei dati in un secondo momento, utilizzerei i miei oggetti framework entità come i miei oggetti di business vanno bene?

Ho un database esistente per il quale ho generato entità e un datacontext e ho classi parziali per tenere i miei metodi e qualsiasi proprietà aggiuntiva (non di database). Ho letto molto sul pattern di repository e su altri modi apparentemente complessi di configurazione, ma non sono sicuro che tutto ciò sia necessario. È un'app .NET Web Form che utilizza Entity Framework 6.1.3 e non avrà test delle unità.

Ci sono altri motivi per cui dovrei evitare un approccio così semplicistico?

c# .net webforms asp.net entity-framework

posta user2023116 20.07.2015 - 21:48

fonte

2 risposte

Leggi altre domande sui tag c# .net webforms asp.net entity-framework

è un modello di progettazione javascript valido quando sono richieste molte istanze? Sta evitando che i campi che rappresentano lo stesso oggetto in diverse classi di comunicazione siano ragionevoli?

score 1 · Answer 1

Non penso che dovresti usarli come oggetti di business. Secondo Vaughn Vernon EF è troppo rigido da utilizzare direttamente come oggetti di business

Utilizzali invece come oggetti di stato. Ciò li avvolge con un migliore incapsulamento della tua logica aziendale. Nel link ho fornito che sto parlando di DDD. Quello che tu chiami come oggetti di business sono chiamati radici aggregate in DDD ma il punto è ancora in piedi.

score 0 · Answer 2

Non estenderei i POCO per usarli come oggetti business. Combinerà la logica del dominio con la logica dei dati e i codici diventeranno molto difficili da mantenere in futuro.

Ma hai anche detto che non avresti test unitari. Quindi forse stai costruendo un progetto unico, di breve durata che non ha bisogno di essere mantenuto e quindi potrebbe essere Ok. Ricorda solo che potrebbe creare molti debiti tecnici che tu (o altri sviluppatori) dovrai affrontare in seguito.