ORM: Design of the service layer

Question

I'm currently writing a medium sized web-application and find myself asking this question many times.

For example, let's say there are users, which have files (one-to-many). How should the UI access the data? One "extreme" would be to let the service layer "only" take care of the lazy loading, i.e.

public interface UserService { public User createUser(String loginName, String password); public Set<MediaFile> getFilesOfUser(User user); }

or, on the other hand, never return entities, only their ids

public interface UserService { public long createUser(String loginName, String password); public Set<Long> getFilesOfUser(long userId); }

This implies the service would need methods for querying (and setting) all "basic" attributes, too

public interface UserService { public long createUser(String loginName, String password); public Set<Long> getFilesOfUser(long userId); public String getNameOfUser(long userId); public void setNameOfUser(long userId, String name); }

This adds quite a bit of code (and possibly additional load to the DB), but also protects from StaleData- or LazyInitializationException.

Subquestion: How - if using the first case - should updating, fetching etc. be implemented? Two methods come to mind

First, I could try to manually update the original reference (because things like collection proxies, version etc. only get updated on the returned object, not the original reference). This simplifies using those entities directly in the UI

public Set<MediaFile> getFilesOfUser(User user) { Set<MediaFile> files = user.getFiles(); if(!Hibernate.isInitialized(files)) { user.setFiles(userDao.findOne(user.getId()).getFiles()); // findOne to re-attach to the session return ImmutableSet.<MediaFile> copyOf(files); }

but also

public Set<MediaFile> getFilesOfUser(User user) { return ImmutableSet.<MediaFile> copyOf(getUser(user.getId()).getFiles()); }

The major difference in those comes to show when using versioning. In the former case, I have to update version etc. manually (user.setVersion(attachedUser.getVersion())) after every update, in the latter, a update call has to re-fetch the entity every time just to set the value:

public void update(User user) { User attachedUser = getUser(user.getId()); attachedUser.setName(user.getName()); attachedUser.setPasswordHash(user.getPasswordHash()); // etc etc userDao.save(attachedUser); }

This does not seem very efficient / unintuitive.

Which is the correct way to go?

EDIT

Just had an other idea related to the "only return id's" method: Services could expose a public "get___ById(long id)" method, which then can be used to at least read the basic values of the entity.

Additionally, one could implement "get___ByIdEagerly(long id)" and return a initialized entity, but I think that's a bad idea.

I have no knowledge of JPA, but your question sounds surprisingly familiar. I suspect an acceptable answer would imply JPA, but here is the generic answer I can provide: there is no "correct" way, as it really all depends on the context (usage scenarios, business/technical constraints, etc.) — user44761
– user44761, Commented Oct 7, 2013 at 12:55
This problem probably is - in it's essence - language-agnostic, I'm just too new to this whole Database / JPA thing to formulate it in an appropriate abstract way — incaseoftrouble
– incaseoftrouble, Commented Oct 7, 2013 at 13:05

incaseoftrouble · Accepted Answer · 2013-10-07 14:17:49Z

So, I changed most of my code to the "only use the id"-approach. While re-writing I realized what my fallacy was: I interpreted references to entities as a representation of the object graph, whereas (I think) these just represent a snapshot of (a subset of) the current graph, with no guarantees to be updated. Designing the "UI-Level"-code around this resolves most of my issues with little to no work:

All events, constructors, etc. just pass the ids of the entities they are refering to. Also the service layer methods only take id's as arguments. If an instance needs information of an entity, it fetches it on demand and discards the entity object as soon as possible, meaning those references are never held outside the scope of a method (Exceptions can be made if you are sure that the values you are reading never get changed - but then, why would you read them again, anyways). This also implies: The service layer returns entities after a modification, but those objects also should never be saved longer than needed.

Example:

public MediaFile addFileToUser(long userId, File file, FileMetaData fileMetadata); public User createUser(String loginName, String password, String fullName, String company); public Set<MediaFile> getFilesOfUser(long userId);

I'm not sure if this is the recommended approach, but from my point of view it seems ok. No idea about the performance impact though (I don't know how hibernate caching works, but it seems logical to assume cacheing by id, so maybe this approach even is kinda fast)

Stack Exchange Network

ORM: Design of the service layer

1 Answer 1

Hot Network Questions

ORM: Design of the service layer

1 Answer 1

Related

Hot Network Questions