launchpad-dev team mailing list archive

[Aaron Bentley <aaron@xxxxxxxxxxxxx>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 11/04/2010 01:44 AM, Ian Booth wrote:
> Yes, I agree that the database representation and domain model used by
> the business logic are coupled. That doesn't equate though to the
> business logic having to operate on the exact same representation of the
> data model as is managed by the ORM layer. There are often subtly
> different requirements in play. The domain model used by the business
> logic is often finer grained than the persistent objects, or there may
> be transformations of the persistent representation to map to different
> "views" on top of a given data set.

You've said this several times, but I can't think of any examples where
it would apply to us, so it doesn't resonate with me.

Perhaps person vs team is an example of this?  The "coarse-grained"
persistent objects use the same table, but they ought to be treated as
different (but related) types in business logic?

>> I don't think that such leakages can be contained at all.  I think that
>> efficiency demands that a significant portion of our business logic be
>> incorporated in SQL queries (or Storm expressions) and database constraints.
>>
> 
> They can be contained if they are kept and managed by the ORM layer and
> what's presented to the business logic is a "clean" object model. SQL
> queries are fine and good ORM implementations allow the mixing of SQL
> queries and their higher level object query language.

It still sounds to me like the queries, which are business logic, would
be implemented at the ORM layer.  Am I understanding correctly?

>>> The fact that the ORM objects are database backed is important because
>>> of the design/modelling comprises required to efficiently map the data
>>> model. This may result in a data model great for efficiently storing in
>>> a relational database but not so good for other things.
>>
>> That's a very big "may".  Can you give some examples of classes whose
>> design is distorted because they are mapped to the database?
>>
> 
> Hmmm. Not easily for lp just at the moment.

That's the biggest problem I have with this proposal.  It sounds like it
*might* be useful if you have certain kinds of problems, but it's not
clear to me that we do have those problems.

Many projects have tight coupling that hurts them, but I think that in
general, we have the opposite problem: too-loose coupling.  We have all
these interface definitions that are mostly duplicates of the model
definitions, and the model definitions in turn are mostly duplicates of
the SQL table definitions.

>> We must also determine that the transformations performed on our domain
>> objects do not result in database constraint violations.
>>
> 
> Yes. Database constraints are a good safety net. But the rules could or
> should also be implemented in the object model.

I don't think we should duplicate logic if we can help it.  Duplicating
logic leads to disagreements between the implementations and increases
the testing burden.

>>>> Following his advice seems to mean stripping the ORM objects down until
>>>> they are just bags of data, and then having a parallel hierarchy of
>>>> domain objects that would apply our business logic on such bags of data.
>>
>>> That's one extreme but not really how it pans out in practice.
>>
>> How does it really pan out in practice?
>>
> 
> In general, there's an object model with is constructed to be optimally
> mapped to a relational schema representation. This is not necessarily
> exactly the same as the object model used by the business logic.

Even if they are not identical hierarchies, it sounds like they would be
substantially similar, at least in magnitude.

>>> There would be similarities - it is after all the same underlying real
>>> world model. But when you start using projections and other data
>>> transformation mechanisms to extract and compose the data model relevant
>>> to a particular use case, the different representations can and do
>>> diverge.
>>
>> If we "compose the data model relevant to a particular use case" do we
>> get an explosion of classes, like providing Person as "CodeReviewer",
>> "BranchUploader", "BugReporter", etc?  What happens when we also care
>> about the branches uploaded by a CodeReviewer?
>>
> 
> No, that doesn't happen, at least on the systems I've worked with.

Okay, clearly I'm misunderstanding what you mean by "compose the data
model relevant to a particular use case".  What do you mean?

We are talking about having different representations of a given ORM
class depending on the use case, right?

>> An in memory store would mean that "testability" would not be an
>> advantage of loose coupling.
>>
> 
> True. But there would be extra set up etc and "baggage" associated with
> running business logic tests.

Okay, I'll grant that business logic tests that didn't need to emulate
persistence could have less baggage.

>> IHMO, redundancy is our biggest problem.  If the table names are the
>> same as the proposed classes, having classes means introducing
>> redundancy.  If the column names are the same as the proposed
>> attributes, having attributes means introducing redundancy.
>>
> 
> There may be slightly different rules in place for how DBAs require
> table and column names to be formed, or certain databases like Oracle
> place a limit of 32 characters on column names so there's not always a
> guarantee that they can be the same. In practice, it's not that hard to
> maintain the separation.

I have not experienced any limitations on naming tables or columns.  I
feel that any duplication that is not necessary wastes effort, both in
implementation and maintenance.  "Not that hard", but harder than
necessary is still too hard.

>> No changes are needed *there*, but changes are required in the ORM
>> layer.  I'm not sure this stands up to cost/benefit analysis.  The
>> benefit of not having to change the calling code may be small relative
>> to the cost of implementing and maintaining a second definition of
>> Person & Team.
>>
> 
> I systems I've worked on in the past, the stability of the domain model
> when tweaking the OR mapping rules is a benefit that hasn't taken that
> much cost to achieve. But there's no one size fits all approach I guess.

It's also easy to miss some of the costs because standard procedure can
become invisible.  I know that happens to me on occasion.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkzSxM0ACgkQ0F+nu1YWqI0xtQCfS5tABTtZuPVlZdCGX8d0NpO8
bl0An3WIjL4/u+CoAs/AhQ4HnqEn24vj
=89Ft
-----END PGP SIGNATURE-----