We had an interesting discussion about this internally at Neo Technology today. We thought it might be of interest to the broader community. I don't think the discussion is over, so it would be interesting to continue it on the public mailing list.
It regards the initial paragraphs of an article posted to dzone recently: http://www.dzone.com/links/rss/the_coming_sql_collapse.html It mentions Neo4j and how the author dislikes a common way of using Neo4j for building applications. It would be interesting to hear suggestions on how to improve this. Forwarded conversation follows: On Fri, Oct 14, 2011 at 10:13 AM, Tobias Ivarsson < [email protected]> wrote: > I found this while reading feeds in bed last night: > > *The Coming SQL Collapse* > http://www.dzone.com/links/rss/the_coming_sql_collapse.html > > (Sent from Flipboard <http://flipboard.com>) > > > The things he say about SQL vs NOSQL is not very interesting, but I'd like > to raise what he says about Neo4j: > > I looked at neo4j briefly the other day, and quite predictably thought >> ‘wow, this looks like a serious tinkertoy: it‘s basically a bunch of nodes >> where you just blob your attributes.‘ Worse than that, to wrap objects >> around it, you have to have them explicitly incorporate their node class, >> which is ugly, smelly, violates every law of separation of concerns and >> logical vs. physical models. On the plus side, as I started to look at it >> more, I realized that it was the perfect way to implement a backend for a >> bayesian inference engine (more on that later). Why? Because inference >> doesn‘t care particularly about all the droll requirements that are settled >> for you by SQL, and there are no real set operations to speak of. > > > He attacks our pattern of building domain models with Neo4j, calling it > "ugly", "smelly" and "in violation of every law of separation of concerns > and logical vs. physical models". Is he right? My feeling is that he is > brain washed with too many so called "best practices", but Neo4j has been my > main model for a long time now, my perspective is likely skewed. I'd like to > hear your thoughts. > > -- > Tobias Ivarsson <[email protected]> > On Fri, Oct 14, 2011 at 10:32 AM, Rickard Öberg < [email protected]> wrote: > > > Well, I'd tend to agree with the author. Mixing persistence details with > the domain model itself is really a bad idea. Infrastructure details should > not pollute the domain logic as it does with the currently "suggested" usage > of Neo4j. But I think both Spring Data Graph and the Qi4j usage model fixes > this, as it allows you to keep many of those things outside of the domain > code. > > /Rickard On Fri, Oct 14, 2011 at 11:45 AM, Tobias Ivarsson <tobias.ivarsson@ neotechnology.com> wrote: > On Fri, Oct 14, 2011 at 11:21 AM, Rickard Öberg < > [email protected]> wrote: > >> On 10/14/11 17:16 , Tobias Ivarsson wrote: >> >>> I was hoping for a bit more elaboration, of why it is a bad idea. >>> >>> Spring Data Neo4j operates mainly in the same way (at least it did when >>> I was part of the design process), it just hides the details of it. >>> >>> The model we suggest is not to mix infrastructure details (nodes, >>> relationships, traversals) with the domain logic. We suggest the domain >>> logic be a separate layer, acting on domain data objects (defined as a >>> set of interfaces). What we do suggest though is for those domain data >>> objects to be implemented as wrappers of nodes and relationships. >>> >> >> That sounds like "transaction script+anemic domain model", which is an >> anti-pattern as well. > > > I'm guessing the anemic domain model is what you are pointing out as the > anti-pattern. I can see how transaction scripts are and ADM usually come > together though. > > References: > > http://martinfowler.com/eaaCatalog/transactionScript.html > http://martinfowler.com/bliki/AnemicDomainModel.html > > > >> Domain logic should be in the domain objects, and so splitting them into >> several layers confuse things more than it helps. > > > I agree with you, SDN "solves" this, and does so well. > > >> So is the bad part of it just the part of having the implementation of >>> your domain data objects deal with the Neo4j API, instead of having DTOs >>> and DAOs that you load from the database, operate on in memory, then >>> store back to the db at explicit points? Or are there deeper issues than >>> that? >>> >> >> It relates to testability (you should be able to test domain objects >> without infrastructure), code cohesion (put domain logic in domain objects), >> and as the article author points out, separation of concerns in general. > > > The testability aspect is interesting and important. I don't have enough > SDN experience to know how it fares in that regard. > > "separation of concerns in general" - anything else to this? or would this > (normally) be achieved when testability without infrastructure is achieved? > On Fri, Oct 14, 2011 at 11:49 AM, Rickard Öberg <rickard.oberg@ neotechnology.com> wrote: > On 10/14/11 17:45 , Tobias Ivarsson wrote: > >> I'm guessing the anemic domain model is what you are pointing out as the >> anti-pattern. I can see how transaction scripts are and ADM usually come >> together though. >> > > Yeah, it's when you use the two together (very common in Hibernate world as > well) that you run into problems, if you do anything but cruddy stuff. > > > The testability aspect is interesting and important. I don't have enough >> SDN experience to know how it fares in that regard. >> >> "separation of concerns in general" - anything else to this? or would >> this (normally) be achieved when testability without infrastructure is >> achieved? >> > > I suggest that you read up on SOLID: > http://en.wikipedia.org/wiki/**SOLID_%28object-oriented_**design%29<http://en.wikipedia.org/wiki/SOLID_%28object-oriented_design%29> > > And in particular SRP: > http://en.wikipedia.org/wiki/**Single_responsibility_**principle<http://en.wikipedia.org/wiki/Single_responsibility_principle> > > Separating the domain objects from the infrastructure is a good start > ("required but not enough"). > > > /Rickard > -- Tobias Ivarsson <[email protected]> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 (Swe); +1 650 450 3806 (US) _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
