Come posso progettare un livello del modello senza ORM e quando dovrei usarlo?

I didn't like the fact that i was tied to a specific ORM implementation...

Perché no? Hai paura che sceglierai quello sbagliato? Sembra un caso di "Non inventato qui". Sarai dipendente dalla lingua scelta, dall'SQL, dal framework web e da una dozzina di altre cose. Un ORM è solo uno di più.

Finché la performance attraverso un ORM è adeguata, la userei. Se le query generate da ORM sono troppo lente per alcune pagine, creare una vista SQL o una stored procedure per recuperare con precisione le informazioni necessarie e associare i risultati a una classe di presentazione personalizzata. Utilizzare l'ORM per il mapping se è conveniente, altrimenti è possibile associare il set di risultati SQL a una matrice di oggetti.

Nel tuo OP hai chiesto un'istanza quando l'uso di un ORM è "cattivo". Non andrei tanto lontano da dire che ORM è cattivo, ma ha conseguenze, non tutte buone.

1. Gli ORM seguono generalmente il pattern Active Record * (perché Data Mapper è un po 'complicato)
2. questo tende ad imporre decisioni di progettazione sul database che favoriscono il codice dell'applicazione

Ecco una grande citazione da un articolo di Bill Karwin che riassume perché questo potrebbe non essere un modello così grande (non sono riuscito a trovare il thread su SO in cui è stato fatto riferimento ...): link

A single Model class may be backed by a database table, or multiple database tables, or perhaps even no database tables. Data persistence should be an internal implementation detail within a Model; the external API of the Model class should reflect its logical OO requirements, not the physical database structure.

Riguardo a "DAL", questo è un acronimo apparentemente semplice che comprende una gamma di modelli. Personalmente preferisco usare generatori di query come Zend_DB o NotORM e scrivere metodi personalizzati per descrivere le relazioni come e quando è necessario. Ci vuole un po 'di manovra in più, ma tu diventi intimo con il modello Domain (al contrario del modello ORM ...) e il database che lo supporta.

Ci sono un paio di libri classici su questo argomento che meritano una lettura se puoi rintracciarli:

Pattern di accesso ai dati: Clifton Nock

Manuale di progettazione di database relazionali

Per inciso, sembra un po 'tragico abbandonare il design RDBMS e l'SQL per interrogarlo sul livello dell'applicazione! Potrebbe non essere la cosa nuova sul blocco, ma è un notevole pezzo di tecnologia che esprime concetti molto raffinati che sono probabilmente più robusti della fase di progettazione a breve termine che verrà applicata alle esigenze immediate di un progetto. Ho visto troppe app che lasciano limiti di integrità nel livello dell'applicazione o non tengono conto dei metodi di indicizzazione / interrogazione impiegati dalla piattaforma DB che stanno utilizzando. Gli ORM sono indubbiamente un bel pezzo di kit, ma lo è anche SQL ...

Ecco un'altra grande citazione sull'argomento che esprime questo sentimento (con riferimento al modello del modulo tabella:

In many ways this approach treats the relational database like a crazy aunt who's shut up in an attic and whom nobody wants to talk about http://martinfowler.com/eaaCatalog/tableModule.html

ed ecco un'altra discussione su SO che è molto pertinente a questo argomento: Vincoli in un database relazionale - Perché non rimuoverli completamente?