Attualmente eseguo il refactoring di un'applicazione WPF basata sui principi del Repository Pattern
. Utilizza Entity Framework
come ORM e Database First. Ognuna di queste entità viene avvolta da Repository
, le cui interfacce vengono quindi utilizzate in Unit Of Work
. Quelle unità di lavoro sono quindi utilizzate da ViewModels
.
Tuttavia, una singola transazione come, ad esempio, CreateInvoice()
interessa diverse tabelle. Ad esempio, CreateInvoice()
inserirà un record Sale
in Sales
Table, dedurrà lo stock disponibile in Stock
Table e così via e così via. Ecco un esempio di codice per questo:
public void Commit(IContainInvoiceInfo InvoiceInfo)
{
_invoiceInfo = InvoiceInfo;
try
{
_uow.BeginTransaction();
InsertInSalesTable();
UpdateCurrentStock();
UpdatePacketStock();
InsertStockHistoryEntries();
InsertInTaxTable();
_uow.Complete();
_uow.EndTransaction();
}
catch (Exception ex)
{
_uow.RollBack();
throw ex;
}
}
private void InsertInSalesTable()
{
_uow.salesrepo.Add(new Sale
{
ID = _invoiceInfo.InvoiceNum.ToString(),
client = _invoiceInfo.SelectedClient.ID,
saledate = _invoiceInfo.InvoiceDate,
totalvalue = _invoiceInfo.GrandTotal,
purchaseorder = string.IsNullOrWhiteSpace(_invoiceInfo.PONumber) ? null : _invoiceInfo.PONumber + "dated: " + _invoiceInfo.PODate.ToString("dd-MM-yy")
});
}
...
Quindi, in pratica, ViewModels sta facendo il lavoro pesantemente inserendo correttamente i dati nelle tabelle appropriate in un database.
Il problema è che dal momento che sto usando l'approccio DB First
di Entity Framework, il modello generato è anemico. Sono classi di dati semplici con assolutamente nessun comportamento.
Potrei incapsulare questa logica nel Unit Of Work
stesso, o anche creare stored procedure nel database stesso, o creare un livello di servizio separato che consumerebbe le Unità di lavoro e quindi fare in modo che ViewModels utilizzi i servizi invece delle Unità di lavoro.
Qual è il posto giusto per incapsulare questa logica di inserimento / aggiornamento?