java - Repository Pattern - How to understand it and how does it work with "complex" entities? -

i'm having hard time understanding repository pattern.

there lot of opinions on topic in repository pattern done right other stuff repository new singleton or again in don't use dao use repository or take spring jpa data + hibernate + mysql + maven somehow repository appears same dao object.

i'm getting tired of reading stuff since imho can't such hard thing displayed in lot of articles.

i see this: appears want this:

         ------------------------------------------------------------------------          |                            server                                    |          ------------------------------------------------------------------------          |                    |                        |                        | client <-|-> service layer  <-|->  repository layer  <-|-> orm / database layer |          |                    |                        |                        |            ------------------------------------------------------------------------ 

the service layer takes *dtoobjects , passes repository layer nothing more "the guy" knows how entity can stored.

for example assume have composition of tools (please note pseudo code)

@entity class toolset {   @id   public long id;   @onetoone   public tool tool1;   @onetoone   public tool tool2; }  @entity class tool {   @id   public long id;   @onetomany   public tooldescription tooldescription; }  @entity class tooldescription {   @id   public long id;   @notnull   @onetoone   public language language    public string name;   public string details; } 

the thing i'm not getting part getting toolsetdto object client.

as understood far write toolsetrepository method toolsetrepository.save(toolsetdto toolsetdto) "knows how store" toolsetdto. every tutorial not pass *dto entity instead.

what's bothering me here if take toolset example above i'd have following steps:

1. take toolsetdto , check if not null
2. for each tool*dto owned toolsetdto
   a) if has valid id convert dto entity otherwise create new database entry
   b) tooldescriptiondto , convert/save database or create new entry
3. after checking above instanciate toolset (entity) , set persisting in database

all complex let service function (interface client) handle this.

what thinking creating e.g. toolsetrepository question here is

• does take toolset entity object or use dto object?
• in case: *repository allowed use other repository objects? when want save toolset have store tool , tooldescription first - use toolrepository , tooldescriptionrepository inside toolsetrepository?
  if so: why doesn't break repository pattern? if pattern layer between service , orm framework not "feel right" add dependencies other *repository classes due dependency reasons.

i don't know why can't head around this. not sound that complicated there's still out there spring data. thing bothering me since don't see how makes anything easier. since i'm using hibernate - don't see benefit (but maybe that's question).

so .. know long question put few days of research it. there's existing code working on right starts become mess because can't see through pattern.

i hope can give me bigger picture of articles , tutorials not beyond implementing very, simple example of repository pattern.

you can read "repository dummies" post understand simple principle of repository. think problem you're working dtos , in scenario, don't use repository pattern, you're using dao.

the main difference between repository , dao repository returns objects that understood calling layer. of time repository used business layer , thus, returns business objects. dao returns data might or might not whole business object i.e data isn't valid business concept.

if business objects data structures, might hint have modeling problem i.e bad design. repository makes more sense 'rich' or @ least encapsulated objects. if you're loading/saving data structures don't need repository orm enough.

if you're dealing business objects composed other objects (an aggregate) , object needs parts in order consistent (an aggregate root) repository pattern best solution because abstract persistence details. app ask 'product' , repository return whole, regardless of how many tables or queries required restore object.

based on code sample, don't have 'real' business objects. have data structures used hibernate. business object designed based on business concepts , use cases. repository makes possible bl not care how object persisted. in way, repository acts 'converter/mapper' between object , model persisted. repo 'reduces' objects required persistence data.

a business object is not orm entity.it might technical point of view, design pov , 1 models business stuff other models persistence stuff. in many cases these not directly compatible.

the biggest mistake design business object according storage needs , mindset. , contrary many devs believe, orm purpose not persist business objects. purpose simulate 'oop' database on top of rdbms. orm mapping between db objects , tables, not between app objects (even less when dealing business objects) , tables.