On Apr 6, 2013, at 11:42 AM, Roberto Guerra <uri...@gmail.com> wrote:
>
>
> +10000. I prefer classical mapping also. Much cleaner. Keeps persistence and
> business logic separate.
the reason I ended up not agreeing with this is because mapping applies
instrumentation to a class. Using a separate mapper means you might see this:
class MyBusinessObject(object):
pass
then elsewhere, you see some code doing this:
my_object = get_some_business_object() # my_object is a MyBusinessObject
print (my_object.first_name)
but what's "first_name"? That field isn't present at all on the class def for
MyBusinessObject, it was applied by mapper(). Is the fact that
"my_object.first_name" exists a detail of persistence or of business logic?
It's in fact both. But we don't define it twice. So the "ideal" of separate
persistence and business design is already out the window.
In the classic usage patterns with Hibernate, things weren't as ambiguous. In
Java, we'd always have this:
class MyBusinessObject {
public String getFirstName() {
}
public void setFirstName(String name) {
}
}
then a hibernate .xml file defines the mapping. In that case, we have a
total separation of persistence and class design. But even Hibernate moved
away from this, in modern use you'd often use JPA annotations to mark the
persistence for "firstName" inline.
The other enormous win with declarative is the mixin stuff. You can produce
patterns like that with mapper() as well, but not nearly as easily.
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to sqlalchemy+unsubscr...@googlegroups.com.
To post to this group, send email to sqlalchemy@googlegroups.com.
Visit this group at http://groups.google.com/group/sqlalchemy?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
