il WTF non ha niente a che vedere con acronimi informatici, sta semplicemente per What the fuck!?
Veniamo al senso di questo post:
Per abitudine nei miei progetti separo le entità del mio dominio in una classe a se e queste entità sono classi semplici senza behaviours, i behaviours eventuali li implemento in classi apposite
Ipotizziamo quindi un'eventuale entità Ordine, nel mio caso il dato viene recuperato dal DAL e inserito nella mia classe Order presente nel progetto "Entities", mentre i behaviours li inserisco in un repository, ipotizziamo quindi in una classe BizOrder che implementa i soliti metodi GetXxxx e il CRUD in generale (in questa classe vengono invocati poi i metodi del DAL e quindi di conseguenza faccio uso delle classi DataMapper, ad esempio nel mio caso una classe DataOrder)
In sostanza io ho una situazione di questo tipo:
progetto Entities
progetto DAL
progetto Business
progetto Presentation (Presentation.WEB, Presentation.WinForm, etc...)
ora per comodità evito il concetto del progetto Service, spesso può essere inglobato nel Business o astratto in un progetto a se sottoforma di webservice o classi piane che in futuro potrebbero essere wrappate da un Ajax Server Layer o altre amenità varie. btw in questo progetto potrei fare uso di DTO
Spesso tra i vari strati comunico con le entità di dominio(progetto Entities), implementato tecniche di Lazy Loading nel DAL (classi interne al DAL, che ereditano dall'entity di base facendo l'override delle proprietà legate ad altre entità o collection di entità ed implementano il Lazy Load)
Tirando le somme, implemento progetti con dipendenze strette, ad eccezione del progetto "Entities" che è conosciuto trasversalmente da tutti gli strati:
Presentation conosce Business e Entities
Business conosce DAL e Entities
DAL conosce Entities
Entities non conosce una cippa
In sostanza le mie classi di dominio sono solo data, senza behaviour e mi chiedo se questo possa essere visto come un'astrazione eccessiva.
Mi cheido questo dopo aver letto un articolo con spunti interessanti, nel quale Andrea suggeriva di unire data & behaviour
Se non ho mal interpretato quanto letto, si faceva un appunto in merito al fatto che con dati e comportamenti divisi in classi diverse, non si poteva scrivere codice LINQ nel caso in cui una proprietà calcolata fosse implementata alla classe rappresentante l'entità (ipotizziamo nel mio caso alla BizOrder con un metodo IsHuge che mi restituisce true se l'ordine è da un 1 milione di euro in totale, regola idiota inventata sul momento)
La mia domanda è la seguente: se l'ipotetico metodo IsHuge lo implementassi come Extension della classe Order, non avrei comunque modo di utilizzare LINQ con una query tipo "from order in orders where order.IsTop() select order" ?
In questo modo supererei i limiti del behaviour in classi di business apposite e potrei sfruttare il progetto Entities per altri eventuali progetti nei quali la business rules non è più valida o varia (anche se a dirla tutta probabilmente non ci sarebbero molti casi reali di riutilizzo del progetto)... comunque eviterei di dover fare refactoring della soluzione qualora io volessi utilizzare LINQ in modo esteso nelle mie classi di servizio
Sbaglio qualcosa nel ragionamento?