locked
Help requested : When to use ORM in Domain driven design and related 6 questions RRS feed

  • Question

  • Hi,

    I want to try using ORM in a sample Health care project. My project approach is as below ...

    1. Requirement Analysis - -Done

     2.1  High level design--Usecase --done.

         2.2 Context maps : done

          2.3. High level design - class diagrams--in progess..

    3.1 Low level design -ER diagram.---to start

        3.2 Low level design : Table relation ship diagram---to start

    4. Implementation :

         4.1  Generating classes & UI

         4.2 DDD implementations etc...

    5. Testing ....

    6. Maintenence.....    

     

    i VE following questions . From the above phases

       1. Can any body suggest an appropriate place for start using ORM.?

      2. should a good architect create classes from the class diagram ?

      3. If ORM is used, i think we dont need any special tools to create classes becos, VS 2008 create classes automatically from ORM. Am i right ?

      4. If we dont use ORM, Please suggest me the best practice to create classes from class diagram ?   

      5. Can we call ORM as data modelling tool ?

      6. can the E-R diagram  be called as data modelling ?

    Thanks

    Devasena


    Ace
    Tuesday, June 29, 2010 2:54 PM

Answers

  • 1) Developers use ORM after the database is designed and built. Model first development requires EF4 and DBA involvement.  Even then I'm not convinced it's a good idea.

    2) Architects don't create classes.  That's programmer work.

    3) The entire purpose of early versions of EF could loosely be described as creating classes.  EF4 is much more usable and I STRONGLY recommend using it over earlier versions.

    4) Don't worry about it.  Developers write classes.  If you're an architect then you don't code.

    5) ORM are about creating code that makes a database appear more object-like for programming purposes. They're not really intended for analysis design or data modelling.  Usually.

    6) Yes.  I also recommend considering data flow diagrams.  At least in early stages of design they're well suited to capturing the parts of processes you understand and highlighting those you don't.  They're also process orientated rather than data orientated like E-R diagrams and intended to be drawn free-hand.  Unless you have ninja skills, visio is a pain to draw such diagrams with. I personally find the Andy vs Visio struggle uses up a lot of my energies.

     

    • Marked as answer by Devasena_ace Thursday, July 1, 2010 11:31 AM
    Thursday, July 1, 2010 7:41 AM

All replies

  • I think you should look at Entity Framework 4 ( vs2010 ).

    That allows you to build a database from a model, generate plain classes and is all round way better than linq to sql or the previous versions of entity framework.

    If you go that route though, you should have a chat with your DBA first.  Auto generating databases isn't good unless you really know your stuff.  You will usually find that DBAs are very good at defending  their territory as well.  Don't upset them.

    Wednesday, June 30, 2010 11:42 AM
  • Andy,

          Thanks for your kind reply.

     

    Can any gurus provide answers to the above questions..

     

    Thanks

    Devasena


    Ace
    Wednesday, June 30, 2010 1:37 PM
  • 1) Developers use ORM after the database is designed and built. Model first development requires EF4 and DBA involvement.  Even then I'm not convinced it's a good idea.

    2) Architects don't create classes.  That's programmer work.

    3) The entire purpose of early versions of EF could loosely be described as creating classes.  EF4 is much more usable and I STRONGLY recommend using it over earlier versions.

    4) Don't worry about it.  Developers write classes.  If you're an architect then you don't code.

    5) ORM are about creating code that makes a database appear more object-like for programming purposes. They're not really intended for analysis design or data modelling.  Usually.

    6) Yes.  I also recommend considering data flow diagrams.  At least in early stages of design they're well suited to capturing the parts of processes you understand and highlighting those you don't.  They're also process orientated rather than data orientated like E-R diagrams and intended to be drawn free-hand.  Unless you have ninja skills, visio is a pain to draw such diagrams with. I personally find the Andy vs Visio struggle uses up a lot of my energies.

     

    • Marked as answer by Devasena_ace Thursday, July 1, 2010 11:31 AM
    Thursday, July 1, 2010 7:41 AM
  • Andy,

     

    Thank you very much for the reply.

     

    Regards

    DevSena

     


    Ace
    Thursday, July 1, 2010 11:31 AM
  • Great stuff as always Andy, just wanted to suggest looking into the new diagram modeling tools in VS2010.  I found that creating simple UML diagrams is miles easier than with Visio.
    Thursday, July 1, 2010 2:21 PM
  • thanks e36m3.
    Ace
    Friday, July 2, 2010 3:18 AM
  • That's interesting.

    I must give those UML diagrams a go.  An extra plus is that UML is something clients ask for.  I've had it on my todo list for a while.  Problem is of course that my todo list has quite a lot of things on it ;^)

    Thanks for the tip.

    Friday, July 2, 2010 8:47 AM
  • Hello Andy,

         I would request you to look at the other  one posted by me "Advice: Key deliverables from Architects in each SDLC" and provide your approach..

         Your todo list may be an answer for that..

    Regards

    Sena

     


    Ace
    Friday, July 2, 2010 10:33 AM
  • I don't really have a single to do list - it varies a lot from project to project. 

    I'm reticent to write a post because I think anything is likely to come over as trite and simplistic.

    Friday, July 2, 2010 2:22 PM
  • Thanks Andy.
    Ace
    Monday, July 5, 2010 5:41 AM