Loading ...
Sorry, an error occurred while loading the content.
 

Re: [XP] TDD - ORM

Expand Messages
  • Rob Park
    1 thing to beware of... I think this is exactly what you want to do and as Ilja mentions will work well with Hibernate (or NHibernate). I ve had problems with
    Message 1 of 8 , Feb 11, 2009
      1 thing to beware of...
      I think this is exactly what you want to do and as Ilja mentions will work
      well with Hibernate (or NHibernate). I've had problems with LINQ for SQL
      (and suspect the same from the entity framework), where you cannot separate
      your domain objects away from the framework. You at least need to extend
      the entity framework generated version, so that subsequent updates in the
      app will work. It was more weight to carry around than I wanted at the
      time... just thought I'd mention it as a possible trouble spot.

      .rob.

      On Tue, Feb 10, 2009 at 5:02 PM, J. B. Rainsberger <jbrains762@...>wrote:

      >
      > On 2009-02-09, at 12:28 , varaprasadnarravula wrote:
      >
      > > I am new to ORMs. My first impression is very conflicting as I think
      > > about designing in TDD way. Generating classes from db tables seems to
      > > be saving lot of work. But what I am afraid of is loosing natural
      > > design
      > > (thought) process that comes with TDD. How can I retain TDD and its
      > > natural design process while utilizing the benefit of ORMs?
      > >
      > If you want to generate classes from tables, but also test-drive
      > controllers and business logic, then at some point these two layers
      > will meet and you'll need to build an adapter. Where most people get
      > into trouble is they want to mock the ORM model classes. This causes
      > them to extract interfaces from the model classes, then try to mock
      > them. Bad idea.
      >
      > Instead, I use the Repository concept I first read in Eric Evans'
      > Domain Driven Design. Each Repository is an interface, and its
      > implementation is the adapter to the generated ORM model classes. It
      > feels like double work, but at least the implementations are mostly
      > straightforward.
      >
      > Of course, if you don't have existing database tables, then I would
      > prefer test-driving the repositories, implementing them in a way the
      > ORM understands, then generating the database tables.
      >
      > Take care.
      > ----
      > J. B. (Joe) Rainsberger :: http://www.jbrains.ca
      > Your guide to software craftsmanship
      > JUnit Recipes: Practical Methods for Programmer Testing
      > 2005 Gordon Pask Award for contributions to Agile Software Practice
      >
      >
      >


      [Non-text portions of this message have been removed]
    Your message has been successfully submitted and would be delivered to recipients shortly.