Pai enumera cateva dintre ele...

Eu nu vad un dezavantaj in a-i spune obiectului "factura" de ex., care contine evident antetul facturii, sa se valideze (drept pentru care se duce la data handler si ii cere regulile de validare pentru antetul facturii) si apoi sa se salveze (caz in care iar se duce la data handler si ii comunica informatiile ce trebuiesc salvate, dupa care data handler-ul se descurca mai departe). Pentru mine obiectul factura e un obiect de bussiness. Ar putea fi bon de consum sau proces verbal de stiu eu ce... particularitatile datorate functionalitarii fiecaruia este ceea ce le diferentiaza, plecand insa de la o clasa cu functionalitate generala, universal valabila, cel mai adesea aceea de a incarca reguli si a uni (pentru incarcare in interfata) sau a fragmenta (pentru salvarea datelor) informatia din sau catre "n" tabele (cu ajutorul data handler-ului), intr-un obiect care imi pune la dispozitie in interfata intregul set de date ce imi este necesar. Lucrand in felul asta pot de ex. sa mai schimb din reguli fara sa fac alt exe si fara sa urmaresc proceduri prin "n" formulare si clase atunci cand trebuie sa redefinesc ceva. Exista limite, desigur, dar depind si de imaginatia ta. Totul este insa incapsulat si cu trasabilitate, pentru ca e scris in putine locuri, si daca iti formulezi ideile in practica intr-un mod in care sa nu-ti tai craca singur (cel mai adesea e suficient sa gandesti simplu, si sa nu amesteci cazuistica prea adanc in obiectele de business), chiar iese ceva dinamic.

- limbajul SQL mi se pare mult mai puternic si in acelasi timp simplu pentru lucrul cu datele;

- nu-i suportat de producatorul bazei de date (si oare de ce ?);

- un limbaj generic nu poate acoperi/lucra eficient cu toate aspectele/caracteristicile unui anumit server de date, ca sa nu mai zic de performanta;

- serverul de date ofera comenzi specifice unor operatiuni ce nu au corespondent in ORM (de ex: OLAP);

- procedura stocata ofera o abstractizare buna in lucrul cu clientul, ori care ar fi el... si nu numai atit;

- serverul e facut sa-ti returneze datele finale, nu date partiale si sa le prelucrezi pe alt nivel (obtin rezultate temporare, tinute pe server, prin aplicarea unor comenzi sql, cu un cursor fac o parcurgere pentru alte prelucrari apoi din nou aplic comenzi sql peste aceste date temporare - orin in ORM ma joc cu aceste date in alt nivel decat cel optim pentru asa ceva).

Obiectul de business e ok, dar una e ce face el si alta e sa mapezi in tot in el tabele/relatii/tranzactii/etc. adica chestiuni care tin de server-ul de date si care acestsa lucreaza optim cu ele !

Si totusi cei cu decizia insista si dezvolta in continuare pe directia lor...