java ee - If I use a facade class with generic methods to access the JPA API, how should I provide additional processing for specific types? -

let's i'm making simple web application using java ee specs (i've heard possible). in app, have 10 domain/data objects, , these represented jpa entities. architecturally, consider jpa api perform role of dao. of course, don't want use entitymanager directly in ui (jsf) , need manage transactions, delegate these tasks so-called service layer.

more specifically, able handle these tasks in single dataservice class (often called crudservice) generic methods. see article adam bien example interface: http://www.adam-bien.com/roller/abien/entry/generic_crud_service_aka_dao

my project differs article in can't use ejbs, service classes named beans , handle transactions manually. regardless, want single interface simple crud operations on data objects because having different class each data type lead lot of duplicate and/or unnecessary code.

ideally, views able use method such

public <t> list<t> findall(class<t> type) { ... } 

to retrieve data. using jsf, might this:

<h:datatable value="#{dataservice.findall(data.class)}" var="d">   ... </h:datatable> 

similarly, after validating forms, controller submit data method such as:

public <t> void add(t entity) { ... } 

granted, you'd want return useful caller.

in case, works if data can treated homogenous in manner. alas, breaks down when need perform additional processing on objects before passing them on jpa.

for example, let's i'm dealing books , authors have many-to-many relationship. each book has set of ids referring authors, , each author has set of ids referring books. normally, jpa can manage kind of relationship you, in cases can't (for example, google app engine jpa provider doesn't support this). thus, when persist new book example, may need update corresponding author entities.

my question, then, if there's elegant way handle or if should reconsider sanity of whole design. here's couple ways see of dealing it:

1. the instanceof operator. use target classes when special processing needed. perhaps maintainability suffers , isn't beautiful code, if there's 10 or domain objects can't bad... it?

2. make different service each entity type (ie, bookservice , authorservice). services inherit generic dataservice base class , override methods if special processing needed. @ point, call them daos instead.

as always, appreciate help. let me know if clarifications needed, left out many smaller details.

the service layer justified need transactions, , need of specific business logic every use-case. making generic doesn't make sense, imho. , having service per entity doesn't make sense either, still imho: entities tightly linked together, , can't created or updated independently service. , of services involve several entities.

the service layer, name indicates, there provide services above layer (the presentation layer). should not have generic interface disconnected reality of application needs do. should provide services ui layer needs. find more logical split services based on use-cases or groups of related use-cases rather entities. , find more logical start implementing ui layer, see services needs, , implement services, rather designing generic services, start implementing ui layer, , fall in 1 of commonly seen traps:

• a whole lot of services don't have use , implemented never used
• the ui layer start calling n low-lever services each button click, forgets transactional integrity, , contains logic should in service layer.