Hi Gregor, > I've been busy the last two evenings with other things (new flat = a > lot of work and Glühwein was also a reason for my non-productive days > ;)). Glühwein (http://en.wikipedia.org/wiki/Mulled_wine#German_and_Austrian_Gl.C3.BChwein) is always a good excuse :-)
> On thursday, I will do some coding and try to introduce my solution. > However, even though I am not that data driven I must admit that JDBC > has a speed advantage over JPA/Hibernate or any other ORM. I had a > look around and found some frameworks which support this approach. For > example, Spring JDBCTemplate or MyBatis. Further, you get rid of the > complexity introduced by JPA /Hibernate for their own sake. I think I > will create a simple DAO which provides convinient methods to access > data and do simple conversions. That said, the problem on the data > representation side is hidden behind the DAO and, thus, is > independent from the actual objects used in the code. I'm very intrigued. Let's see where this goes. If possible, do not focus on the _perfect_ design. Do something that works for now. We can all adjust it later together! > Fabrice, you recommended to redesign the data model from the bottom > up. If we stay with relational data, this means the creation of > tables, etc.. Philipp already did a great job by commenting his > drawings. A month ago, I also had a similar idea in mind. By then I > was reading the favorite "Domain Driven Design" book from Eric Evans > who wants developers to focus on the domain of interest first and > identify relevant concepts (don't get confused here, with concept I > refer to a real world object with properties) and their relationships. > Given these objects, Use Cases are defined and at last code is > written. Domain objects then often become entities as they somehow > need to be persisted. With this in mind, one can see the data driven > approach as bottom-up and the domain driven approach as top-down > solution to the same problem. Although, I would rather say, they > complement each other. My suggestion is, to not alter the interface of > domain objects, identified by Philipp and Steffen, but enhance their > data representation. As a said before, one way could be to hide the > data centric part of the application behind DAOs. Sooo, you're suggesting to leave the org.syncany.database classes as is and add an SqlDao? Best, Philipp -- Mailing list: https://launchpad.net/~syncany-team Post to : [email protected] Unsubscribe : https://launchpad.net/~syncany-team More help : https://help.launchpad.net/ListHelp
