Sure, it's pretty much what is listed here:
http://datamapper.org/doku.php?id=why_datamapper
* Identity Map, eager loading and lazyness - The server that will be
hosting some of my applications (yes, I'll be using rails) doesn't have much
resources so I need to achieve the best performance that I can get. After
some googling I've found out that DM performs better than AR (I don't
remember if I found a comparisson to Sequel) and also I deal a lot with text
properties that could be eager loaded
* Mappings inside model - I don't like the idea of having a blank class as
my model like AR and Sequel. I'm actually used to write config files for
that in PHP and C# but if I could do it only in one place would be better,
also it is very "human-friendly" (I couldn't find another word for it) since
we all know what a property means.
* Mixins - I don't like the idea of being forced to make my models inherit
from some base class that doesn't have meaning in my domain model like AR
and Sequel does
* Plays well with others - I have plans to gradually replace some legacy
that will need to integrate with other parts of the system through database
* Query interface done in ruby - I just like the idea
The other thing is since DM doesn't look for db tables in order to "build"
properties and map the entity like AR does (and probably Sequel), it plays
really well with TDD if you also have a domain repository that comunicates
to infrastructure (if we follow the idea I mentioned last message would be
DM repository)
These are the steps that I usually follow when I'm working on my domain:
- Implement models needed
- Implement a fake domain repository that would really act as a
in-memory collection so that I don't bother storing data in db, it can be
just a simple hash like {model_primary_key => model_instance}. If we follow
DDD it would be just one per aggreate root
- ... implement whatever features that needs the models (using TDD) ...
- When finished, hook up my domain repository with persistence and run
all tests again
I don't know if you guys like this approach but I think it really make you
focus on your domain and its tests while you are working on it. Since DM
doesn't need the table to build model's properties it means that you don't
need to run migrations every time you make a change to your models.
That's an idea that I got from "Jimmy Nilsson - Applying Domain-Driven
Design and Patterns" book
Well, these are the reasons that I can think about right now.... What do you
think?
As I said before, just let me know if you can't understand some part of the
message.
Regards,
--
Fábio Rehm
On Thu, May 7, 2009 at 2:54 AM, dusty <[email protected]> wrote:
>
>
> > I really like the way DataMapper works, I think it is much better than
> > Sequel and Rails ActiveRecord and that's why I am here, I think it can
> > be a good start to do the things that I said.
> >
>
> Fabio,
>
> This is an interesting conversation. Do you mind elaborating on that
> point above a bit? What is it about DM that you like better than
> ActiveRecord and Sequel? Just curious.
>
> Thanks
> >
>
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"DataMapper" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to
[email protected]
For more options, visit this group at
http://groups.google.com/group/datamapper?hl=en
-~----------~----~----~----~------~----~------~--~---
