I'm developing kind of a social network with neo4j, and i wanted to make my Node object a bit more specific for my own needs. Does it considered a good practice to wrap a neo4j Node object or to inherit from it?
My problem with the wrapping approach arises when indexing the nodes objects with the built in Lucene engine. For example, what benefits will i earn if i'll wrap my Node object with a "Profile" class (with methods such as "addFriend", "setFirstName", etc..), but on the other hand, whenever i will run a query against my index i'll get back raw Node objects and not my wrapped objects? I can make some dirty solution for this case, by saving a reference for the wrapped object inside my node properties, but it looks very strange for me to do it.
What would you recommend to do in such case, in order to get a clean and well designed code?
Thanks.
I have found that wrapping a Node does not lead to very maintainable code/design. As you mentioned, one thing you need to take care of is not returning a Node but translating it to your domain object.
If your object has mostly getX methods, then you can just execute Cypher queries, compose your domain object(s) and return those. You don't even need to wrap the Node in this case- all you need is some property that you can use to look up the Node.
If you have setX methods, then you can update the Node via Cypher statements either via a save that updates all properties or on each setX (not great, as you'd be updating too often the setX method now implies persistence). Either of the two approaches does not require the Node to be wrapped.
I tried in earlier projects to wrap the Node but found that it leads to much more trouble and a generally smelly design. Now I work with pure domain POJOS's and keep Neo4j code in the persistence layer only, and this works much better for me. You haven't mentioned which language you're using- if Java, then I believe Spring Data can take care of a lot of boilerplate code.
Put your search code INTO the class they belongs to.
If you need to get, I don't know, something like getFriends from a Post class, you will create the method fromPosts into the Person class, and the getFriends method into Post.
From post, you will call the query from Person class, execute the query and return an Array / List of the nodes mapped into the Person class.
So your getFriends method into the Post class will be something like:
Person.fromPosts(self).results.map { |node| Person.new(node) }
Is simple to do that doing just a map of the result with a Person.new (or new Person, depend from which language are you using) and pass the node to the Person. This means that you must have a new method that populate object from a node.
Spring Data Neo4j is the definitive solution to your need, it maps annotated entity classes to Neo4j with advanced mapping functionality and provides access to nodes and relationships at different levels of abstraction.
Related
I was thinking about passing an object to another object, and how it can get complicated. If object A and object B are created in the main class, and object A creates object C, how can I pass object C to object B? Or should I never create an object in another object and therefore never get too far away from the main class?
This got me thinking of a situation in which this might occur, but couldn't exactly match it up in my head, but I thought, what if I create two objects, and have a class that determines collision based on location properties of the objects. In the main class I can pass the two objects to the collision class, and then in the main class I can do some work based on the result. This makes sense, but is this the best way to find collision? Or should I make the collision class static?
Thanks for any replies to the two questions, sorry for not being more specific but I'm trying to wrap my head around the oop concepts.
The concept you are thinking of is called dependency injection. You are not the first one to think at this kind of problem of course.
Most of recent OOP frameworks handle that dependency injection for you. An example of implementation is to use configured services (SOA) in specific configuration files (JSON, YML, XML, ...) referencing your classes. Then the framework will instantiate all your services in the right dependency order for you!
If you want to code it by your own, you certainly should code a dependencyInjectionHandler or servicesContainer which do all the process of injecting objects into each others.
If you come from the PHP world, you can look at an implementation on Symfony2 for example.
Prefer Javascript? Take a look at Danf.
You should be able to find at least one existing implementation in almost all recent languages.
As the Dependency injection principle tells us - you should never create a Dependency (in you're case Object C) in your object, if you want to use another object you should inject it to the dependant object, this is called - inversion of control, the most popular and best practice is to inject you're dependencies in the constructor.
As to where you create them - like you suggested create them at the top (you're main function as you said) of you're a code and inject them all the way down. Depending on the language and framework you are using you can find lots of tools to help you manage it it a bigger scale app's - those tools usually called DI containers.
Good luck.
I am doing something I have never tried before. I am trying to create dynamic UI and bind it to a dynamic model. In other words, my web service is going to send back a small metadata description of my UI and the raw data to bind to it. Therefore, at build time, I don't know what UI I will be constructing and I don't know what my model will be. Binding them together seems VERY difficult if not impossible.
Mvx allows me to bind UI directly to a model WITHOUT it being an MvxViewModel. However, if I bind directly to the Model returned by the web service, I lose the ability to RaisePropertyChanged() since that only comes from MvxViewModel.
Normally, I would write a ViewModel that wraps the Model and have all the wrapped setters call RaisePropertyChanged(). However, in this case, my model is dynamic so I can't wrap it with a ViewModel at compile time since I don't know what it is until runtime.
Is there some cool trick I can use to construct a ViewModel that can wrap any C# model class and send out property changed events without knowing what properties the model class has until runtime?
I just discovered the DLR and the DynamicObject which seems to be perfect, but due to Apple restrictions, it will not work on Xamarin.iOS.
Without teasing DynamicObject into life on iOS, the main approaches that think of are:
You could change your webservice generation code so that it produces INotifyPropertyChanged - I've used libraries that do this - e.g. http://stacky.codeplex.com/SourceControl/latest#trunk/source/Stacky/Entities/Answer.cs - and if you can't change the webservice code generation itself, you might still be able to wrap or pervert the generated code using some kind of t4 or other templating trick.
You could investigate some kind of code that maps the web service objects to some kind of observable collection (Kiliman has suggested this in comments)
You could look at some kind of valueconverter (or maybe valuecombiner) which does the binding - I can fairly easily imagine a valueconverter which takes a wrapped model object and a string parameter (the property name) and which uses those two together (with some reflection) to work out what to do. I'm not as sure how this one would work with nested model objects... but even that could be possible...
You could look at some kind of custom binding extension for MvvmCross. This isn't as scary as it sounds, but does require some reflection trickery - to understand what might be involved take a look at the FieldBinding plugin - https://github.com/MvvmCross/MvvmCross-Plugins/tree/master/FieldBinding
During the actual data-binding process, the plugin will be called via IMvxSourceBindingFactoryExtension - that would be your opportunity to hook into some other custom change event (rather than INotifyPropertyChanged). It might take a little experimentation to get this right... especially if you have nested objects (which then require "chaining" within the binding)... but I think it should be possible to produce something this way.
I am not sure if what I finalized on supports all possible functionality, but so far, it seems to satisfy everything that I need.
I really liked the idea of writing my own IMvxSourceBindingFactoryExtension. However, in investigating how to do that, I started playing with the functionality that already exists within MvvmCross. I already knew that MvvmCross would honor an ObservableCollection. What I didn't know was that I could use [] in my binding expressions AND that not only would integer indexers work, but also string indexers on a Dictionary. I discovered that MvvmCross sample code already has an implementation of ObservableDictionary within its GIT repo. It turns out, that is all that I needed to solve my problem.
So my model contains static properties AND an ObservableDictionary<string,object> of dynamic properties where the key is the name of the dynamic property and the value is the value of the property.
My ViewModel wraps this model class to send out PropertyChanged notifications on the static properties. Since the Dictionary of dynamic properties is observable, MvvmCross already handles changes to members of that dictionary, including 2-way.
The final issue is how to bind to it in my binding expression. That is where the [] comes in. If my ObservableDictionary property name is called UserValues and it contains a value at key user1, then I can 2-way bind to it by using: UserValues[user1] and everything seems to work perfectly.
One issue I see is that I am now requiring my dynamic data source to return an ObservableDictionary to me instead of just a Dictionary. Is that asking too much?
I've been working with NHibernate for quite a while and have come to realize that my architecture might be a bit...dated. This is for an NHibernate library that is living behind several apps that are related to each other.
First off, I have a DomainEntity base class with an ID and an EntityID (which is a guid that I use when I expose an item to the web or through an API, instead of the internal integer id - I think I had a reason for it at one point, but I'm not sure it's really valid now). I have a Repository base class where T inherits from DomainEntity that provides a set of generalized search methods. The inheritors of DomainEntity may also implement several interfaces that track things like created date, created by, etc., that are largely a log for the most recent changes to the object. I'm not fond of using a repository pattern for this, but it wraps the logic of setting those values when an object is saved (provided that object is saved through the repository and not saved as part of saving something else).
I would like to rid myself of the repositories. They don't make me happy and really seem like clutter these days, especially now that I'm not querying with hql and now that I can use extension methods on the Session object. But how do I hook up this sort of functionality cleanly? Let's assume for the purposes of discussion that I have something like structuremap set up and capable of returning an object that exposes context information (current user and the like), what would be a good flexible way of providing this functionality outside of the repository structure? Bonus points if this can be hooked up along with a convention-based mapping setup (I'm looking into replacing the XML files as well).
If you dislike the fact that repositories can become bloated over time then you may want to use something like Query Objects.
The basic idea is that you break down a single query into an individual object that you can then apply it to the database.
Some example implementation links here.
Is there a thread safe way to ensure unique vertices are created by a framed graph? Consider the following:
Node n = framedGraph.addVertex(1, Node.class);
Node m = framedGraph.addVertex(1, Node.class);
System.out.println(n.equals(framedGraph.getVertex(1, Node.class)));
System.out.println(m.equals(framedGraph.getVertex(1, Node.class)));
prints true, false.
I'm looking for functionality similar to the get or create unique node functionality provided by Neo4j (which is the backing graph in this case).
As an aside - is there a way to use non-numeric ids?
Node m = framedGraph.addVertex("http://example.org", Node.class);
System.out.println(n.equals(framedGraph.getVertex("http://example.org", Node.class)));
prints false
Neo4j and most Graph implementations of Blueprints ignore the ID parameter. Aside from TinkerGraph, they generally all assign their own IDs without methods to create your own. You could always use IdGraph to help simulate your own ID.
Blueprints doesn't maintain the notion of "get or create". You have to implement that yourself or I suppose it's possible to reach down into Neo4j code to do it, with the expectation that your code is no longer portable from one graph to another. In that way, perhaps you could build a graph wrapper implementation similar to IdGraph that exposed a getOrCreate() method. At least that way, you still get to work with the Graph interface and the such logic is encapsulated within that. Of course, that won't help with enabling such functionality directly in Frames.
I have a FethViewController and a DisplayViewController...
FethViewController has a method in it that fetches JSON from a webservice.
I want to access that JSON object or rather perform the fetch method in DisplayViewController.
How do I do this? I tried this but it didn't work.
Please help.
Without understanding the broader context of your application architecture, I'd say you have two options:
Dependency injection - Since you fetch JSON in the context of a view that precedes a distal view that also needs the JSON, then one option is to pass the JSON object along the hierarchy - i.e. to your UITabBarController etc. I believe that the link you posted in the question refers to dependency injection. When you say "it didn't work", I'm not sure exactly what you mean by that.
Make the JSON object a property of a singleton class - Perhaps you could create a singleton class that manages network access. Then objects that have obtuse relationships in your object graph could access the network and the results of network calls without the messiness of dependency injection.
Finally, I'm not asserting that either of these is better than the other (or better than other alternatives) because we understand little of your application's goals and remaining architecture.