Entities as Domain objects

[Radhakrishna Kalyan]

Hi,

I would like to know is it a good practice to expose the database entities as domain models?

Kalyan

[Steve Klabnik]

Nope.







More seriously, no, there shouldn't be a 1-1 correspondence between
your database tables and your domain models. See the years of Rubyists
fighting with ActiveRecord.

There also shouldn't necessarily be a 1-1 correspondence between your
domain models and your resources, either.

[Felipe Sere]

From someone that is in the middle of a big refactoring BECAUSE the Java objects had DB annotations and XML annotations and were used in the business logic: don't do it. 

There is a simple code smell: if you see yourself adding @Transient or similar annotations, then your object is doing to much. 

Furthermore: how would you offer alternative representations if you we're tied down by your DB objects? 

 

--
You received this message because you are subscribed to the Google Groups "API Craft" group.
To unsubscribe from this group and stop receiving emails from it, send an email to api-craft+...@googlegroups.com.
Visit this group at http://groups.google.com/group/api-craft?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

--
Gruß,
Felipe

[Radhakrishna Kalyan]

Then I will keep a separate model for each entity and a mapping class to map the entity to model and vice verse.

Thank you for the answers.

For the question

how would you offer alternative representations if you we're tied down by your DB objects?

I believe refactoring is the only option. I would love to hear if any one have better solution.

Kalyan

Thanks and Regards
N Radhakrishna Kalyan

P:  +46 768 800 824
http://about.me/nrkkalyan

[Felipe Sere]

A pattern we started using is something we call a "Mutator". 

It takes the domain object, the Headers and usually a UriInfo Obeject and decides based on the Headers which Representation Object to construct.

[Kevin Swiber]

I defined a few different API-Over-*-Models here: https://groups.google.com/d/msg/api-craft/rGPS2uwG5gs/Bx-8NCo9SekJ

"Good practice" depends on your goals, of course.

There are use cases for an API-Over-Data-Model approach. Sometimes one might want to expose a thin HTTP layer over their database to provide access to a platform that doesn't speak the native database protocol, for instance. Working in enterprises with tons of legacy code, this can be a common issue. Also, access to the HTTP service might be far less restrictive than access to the database directly. This is sometimes a use case, though often occurs with complex security politics in big organizations.

And then there's speed. If the goal is to expose a read-only API that maps exactly to the data model, there are options to get this up and running quickly. Time-to-launch can be drastically reduced.

However, as complexity increases, it makes sense to travel down the chain to API-Over-Domain-Model and finally API-Over-Application-Model (essentially your resource model at this point).

Cheers,

--
Kevin Swiber
@kevinswiber
https://github.com/kevinswiber