The situation we are facing currently is Model Entities and database logic are tightly interweaved together which is making unit tests impossible. So, I decided to go with designing a Repository pattern. The basic structure of storage model what we see through Com interactions Root-Children[each child is another Root]. It's a tree structure. Understanding this, the Repository we designed is RootRepository for CRUD operations on root and ChildRepository internal to RootRepository for CRUD operations for child. We decided Create for only creating an entity but not to persist it but update will either insert only if no entity is key is not found in DB or to update upon found. Read will fetch the entity by key. So while interacting with the Repository API we decided to get entity first using key and if it is null then call Create basic entity(Repository uses factory) and it can be updated if it is required and persisted back to DB using update. No child can be persisted itself since it is an Value object pointing to another entity. To persist child, we have to persist the child referring entity first and later request root Repository to create child object and upon can be added to parent children collection and parent persistence is called so than children will be persisted along with parent.
So, I wonder about the methodology we are following and design pattern is really upto standard. As far as we know this is the only way we can get support for unit testing and test with minimal data mocks. I looked all around on web for getting ideas for building repositories but nothing helped me. Most of my questions here will be addressed in our unit tests but I wonder if there is any design pattern exist already. At this early stage it is easy to migrate to any standard framework if exist and I hope I will get any directions from you guys.