E-R per strategie di progettazione OO?

Question

Sto ancora imparando tutti i poteri di progettazione OO e hanno molta più esperienza nel database (in particolare, E-R) progetta. Ogni volta che mi avvicino un problema e tentare di venire con un disegno seguendo strategie OO, i miei diagrammi UML (classi, per esempio) viene fuori cercando come un disco di ripristino. Ho letto / sentito che è poi intelligente per mappare una classe per ogni tavolo e lavorare da lì ... Ma questo non sembra mai veramente arrivare da nessuna parte ed i miei disegni sono molto alto (cattivo) di accoppiamento, che, a quanto ho capito, è un grande "no-no" in OO.

Qualche ricerche Google ha restituito alcuni colpi in movimento da E-R per OO, ma nulla che in realtà forato a casa per me. Qualcuno ha qualche materiale su questo argomento, o forse hanno lottato con questo problema simile?

Per espandere solo un po ', i miei progetti OO tentativi tendono a muoversi verso una persistente elemento di archiviazione dati implicita che non esiste necessariamente in un design OO.

Grazie per qualsiasi consiglio!

Answer 1

database Systems:. Un approccio pratico alla ... è il libro di testo (capitolo 3 ~ 4) che vi consiglio vivamente

Credo che le differenze fondamentali di dati (modello relazionale) e il programma sono la lacuna principale tra E-R e progettazione OO. Si può disegnare disegno schema del database in UML, ma non è così significa che modello di dati realational sarebbe diventato qualsiasi significato sensibile OO paradigma.

I programmi, da un altro lato, focus su elaborazione correttamente con disciplina riutilizzabilità. I dati, tuttavia, si concentrerà su persistente correttamente con la disciplina delle prestazioni.

Anche se ci sono alcune tecniche per facilitare la fessura (lik O-R Mapping), ma ai fini di base sui dati / programma non sono completamente gli stessi.

Quindi penso che la OO è solo una tecnica di astrarre il disegno, non l'obiettivo del progetto.

Answer 2

mi piacerebbe sospetto da quello che scrivete che avete bisogno di più esperienza / conoscenza di alcuni principi di progettazione di base OO, in particolare ereditarietà e polimorfismo. Una buona comprensione di questi concetti può aiutare a capire meglio le relazioni tra gli oggetti, e il modo in cui devono essere accoppiati.

Dato i tuoi commenti sulla tua OO disegni in movimento verso un elemento di archiviazione dati persistenti implicita, si potrebbe anche voler guardare in concetti come Aspect Oriented Programming (La primavera è un ottimo strumento per questo). Inoltre, sguardo in quello che un ORM come Hibernate può fare, e come lo fa (questo può essere un po 'avanzato, però).

Answer 3

Non c'è davvero solo un modo per imparare la progettazione del software orientato agli oggetti: imparare da zero. Non troverete tutti i collegamenti per convertire la vostra conoscenza di un altro metodo di progettazione del software in una comprensione di progettazione orientata agli oggetti. È necessario iniziare con le basi, come tutti gli altri: incapsulamento, astrazione, is-a-e ha un rapporto, ecc

.

Answer 4

E / R concept del modello può aiutare ogni volta che è necessario progettare le relazioni tra entità. Si consiglia di non preoccuparsi come stanno andando da attuare in fase di progettazione: il può essere convertito in classe, DataTable, XML, ....

quello che stai chiedendo è un po 'diverso. In un piccolo sistema o quando la logica di business non è troppo complessa è possibile avere un oggetto modello di dominio che si presenta come il Data Table.In questo caso si può avere un oggetto per tabella. Questo modello è chiamato "Pattern Tabella Module"

http://martinfowler.com/eaaCatalog/tableModule.html

Usa NHibernate o EF o qualsiasi altro ORM in un sistema come quello mentionated in precedenza si tratta di uno spreco di risorse e di tempo perché si sta aggiungendo un layer che non si ha realmente bisogno