> On Apr 6, 2013, at 11:42 AM, Roberto Guerra <uri...@gmail.com<javascript:>>
> 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.
>
>
>
I preferred the old way of doing things in Hibernate. I still do it that
way when I work with Java. Sprinkling annotations in code is not a best
practice in my opinion. It ties you to a framework.
I don't really have an issue having all the field definitions in the
mapper. I just make sure I write proper doc strings. It allows me to
cleanly separate business logic from persistence details. I normally keep
all my persistence details in a separate logic that gets injected at the
boundaries if I need to do persistence. It also allows me to mix different
databases and even mix rdbms with nosql if I the need arises. I also get
the added benefit of having very fast unit tests. My tests for persistence
are separate and don't interfere if all I'm adding is a new feature or
algorithm.
Most of the time, I wrap the fields in @property anyway, so in the end the
fields do end up in the object after all. It is just an old Java habit of
mine to do that.
--
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.
