Oggetto dominio che utilizza DAO all'interno di una transazione

Immagino tu intenda qualcosa come .nets TransactionScope.

Using(var t = new TransactionScope())
{
    DAL.Add(obj1) //dal automatically finds the transaction scope and enlists. Transaction created
    DAL.Remove(obj2) // sql executes in transaction
    t.Complete() //any db transactions are committed
} 

Sebbene sia possibile utilizzare l'ambito della transazione all'esterno del DAL e fare in modo che tutto funzioni come previsto, si basa sulla libreria di connessione database sottostante che supporta TransactionScopes.

Poiché lo scopo del DAL è di astrarre quell'implementazione sottostante dal codice chiamante; il tuo codice chiamante non può contare sul DAL che rispetta l'ambito della transazione.

Quindi direi che è una cattiva pratica.

Al di là della risposta soddisfacente di Ewan, per ottenere maggiori informazioni, dobbiamo esaminare più a fondo ciò che viene suggerito quando dici: "livello di servizio / applicazione" .

La terminologia dei servizi, Servizi nella progettazione guidata da domini ( DDD) , è applicabile a molte cose in DDD. Tuttavia, la nozione di un servizio di dominio, o di alcuni, solo il servizio:

When a significant process or transformation in the domain is not a natural responsibility of an ENTITY or VALUE OBJECT, add an operation to the model as standalone interface declared as a SERVICE. Define the interface in terms of the language of the model and make sure the operation name is part of the UBIQUITOUS LANGUAGE. Make the SERVICE stateless. -- Eric Evans Domain-Driven Design

I servizi di dominio orchestrano le collaborazioni che incrociano oggetti di domini multipli. In tal modo, quasi certamente richiedono l'uso di una forma di coordinamento transazionale tra gli oggetti del dominio.

Inoltre, Qualcuno può spiegare la differenza tra il dominio e i servizi delle applicazioni :

Domain Services : Encapsulates business logic that doesn't naturally fit within a domain object, and are NOT typical CRUD operations - those would belong to a Repository

Anche in questo caso, i servizi di dominio forniscono un'interfaccia per le operazioni aziendali e implementano la logica di business che coordina le operazioni CRUD degli oggetti di dominio e richiederà sicuramente un qualche tipo di integrità transazionale.

I servizi applicativi devono essere distinti dai servizi di dominio. I servizi applicativi, non dovrebbero richiedere l'accesso alle transazioni dell'oggetto dominio. Se gli oggetti di dominio singolarmente non forniscono la funzionalità richiesta, la logica di business necessaria per orchestrarli dovrebbe essere collocata in un servizio di dominio vicino o con gli oggetti di dominio.

Is it considered good practice to start a transaction in the "service/application" layer, and then have objects in the domain model make DAO calls which participate in that transaction?

Non è consigliabile esporre i dettagli di implementazione transazionale del livello dominio (ad esempio avviare la transazione ottenendo ID transazione o oggetto) al livello applicazione , che contiene servizi applicazione .

È necessaria pratica per mantenere l'integrità per il livello di dominio , che contiene servizi di dominio e oggetti di dominio , per avere accesso alle capacità transazionali, come l'avvio delle transazioni.

Se l'applicazione richiede il coordinamento (transazionale) tra gli oggetti del dominio, creare un servizio di dominio per implementare la logica di business ed esporlo tramite un'interfaccia di servizio.