Esiste una differenza tra un oggetto aziendale e un'entità?Oggetti business vs. entità
Se dovessi definire un tipo di classe POCO, ad esempio una classe di prodotto, si tratterebbe di un oggetto aziendale o un'entità?
public class Product {
public int ID { get; set; }
public string Name { get; set; }
public double Price { get; set; }
public string Sku { get; set; }
}
Nota non c'è alcun funzionalità all'interno di questo oggetto.
Lo chiamerei DTO (oggetto di trasferimento dati). Li ho anche visti come "Classi di proprietà" nei tempi passati. NON lo chiamerei Business Object perché non ha alcun comportamento e, per definizione, i BO sono definiti dal loro comportamento.
Ciò è in contraddizione con ciò che dice Wikipedia: http://en.wikipedia.org/wiki/Business_object - "Mentre un programma può implementare classi, che in genere finiscono in oggetti che gestiscono o eseguono comportamenti, un oggetto business di solito non fa nulla ma mantiene un insieme di variabili o proprietà di istanza " –
Non penso ci sia una chiara distinzione tra oggetti aziendali ed entità. Diversi praticanti sembrano usare versioni diverse.
Vedere questi commenti per Ayende.
Li considero uguali, anche se forse nel caso di alcune classi controller-like (che operano sul modello di dominio) nel proprio livello aziendale, potrebbero non essere chiamate entità. Direi che classi come Product sono sia oggetti business sia entità, mentre un ProductController sarebbe solo un oggetto business. Un'entità rappresenta un oggetto modello di dominio - un utente, un libro, un'auto, ecc., Qualcosa che contiene anche dati propri. Penso che sia solo questione di nominare e non sia importante, io tendo ad usare entrambi i termini in modo intercambiabile, ma di solito uso le "regole" che ho descritto sopra.
Il termine "entità" viene normalmente utilizzato come un modo più pretenzioso di dire "cosa". Prendiamo ad esempio diagrammi di reazionarietà di entità - diagrammi che mostrano la relazione tra le cose.
Gli oggetti di business sono semplicemente cose (oops, entità) nel dominio aziendale. Direi che il tuo prodotto è un'entità commerciale - confrontalo con say a String, che è una cosa nel dominio dell'implementazione.
Sono d'accordo con la descrizione "entità" ma si mescola "entità aziendale" con "oggetto business". – Gray
Nella mia esperienza le entità sono solitamente associate a CRUD. Gli oggetti business possono anche essere oggetti non persistenti come strategies, politiche, ecc.
Tutte le entità sono oggetti business, ma non tutti gli oggetti business sono entità.
Le entità sono oggetti business la cui identità non è definita dai relativi attributi, ma da un identificatore, come l'ID del prodotto.
Un esempio di oggetto business che non è un'entità potrebbe essere Colore. Il colore deriva la sua identità dai suoi valori RBG.
Mi riferisco, ovviamente, a Entities and Value Objects in Domain-Driven Design.
Direi che un colore è considerato un * valore oggetto *. È identificato dal suo valore e più istanze con lo stesso valore sono considerate identiche. Di solito anche i VO sono immutabili. Il colore rosso non cambia. –
Esiste una differenza tra un oggetto aziendale e un'entità?
Wikipedia definisce "business object" per essere uguale a quello che io chiamo "entità". La confusione per me con questa definizione è nella parola "business" perché "business logic" è ortogonale alle entità. Una "entità" (DTO, "entità di dati", ecc.) È un oggetto con campi e metodi di tipo get/set. Conserva i dati ma contiene una logica minima (se presente).
Un oggetto "business logic" o "business rules" incapsula la logica di ordine superiore necessaria per lavorare con queste entità. Usa i campi delle entità per prendere decisioni e per modificare e mantenere le entità come necessario.
Secondo le mie "regole" che ho descritto nella mia risposta, la classe che hai presentato sarebbe stata un'entità. –