What is the "law of separation of concerns and logical vs. physical models", and why is it a law?
-----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Tobias Ivarsson Sent: Friday, October 14, 2011 8:49 AM To: Neo user discussions Subject: [Neo4j] Article: "The Coming SQL Collapse" 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<ht > tp://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 _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
