https://github.com/klaussilveira/neo4j-ogm-bundle
https://github.com/jadell/neo4jphp
I am looking for more stable/ more active and wanted to see if you any one had experience with either one of them?
Neo4jPHP is a simple REST client. You don't get any object mapping from it. If you don't like using ORMs and prefer to do your own querying/lookups, it is probably more your style.
Neo4j-OGM is a wrapper around Neo4jPHP that adds in ORM-type capabilities, annotations on your domain classes and a repository pattern. If you have ever used Doctrine or Propel, you will recognize the style and syntax.
My opinion: if you are used to using an ORM or ODM, go with Neo4j-OGM. If you like to do more tweaking and "bare-metal" optimizations, go with Neo4jPHP.
Related
I want to avoid getters/setters hell in my entities (here is the reason: http://ocramius.github.io/doctrine-best-practices/#/53), but both most popular admin panel generators:
Sonata and DoctrineORMAdminBundle
https://github.com/javiereguiluz/EasyAdminBundle
need getters and setters to render view.
My idea is to create DTO object instead (http://ocramius.github.io/doctrine-best-practices/#/57) and then use named constructors to create entities. I want to call named constructor inside my service. What is the best way to force admin panel generators to use my DTOs to persist/update data, can you give me an idea and/or example of good practices in that case?
The only way I imagined is to use DTO instead of real Entity, call prePersist/preUpdate hooks and use custom service, but it looks confusing.
One of the most important aspect of DDD is to correctly identify your bounded contexts (usually aligned with your sub-domains) and determine the appropriate technologies and architectures to use within those.
An admin panel sounds like something generic that would be very CRUD in nature. If that's the case then don't try to fight it and embrace CRUD within that BC. Trying to implement a pure domain model in a BC where it isn't needed would make things more complicated than they need to be.
However, if you determined that the complexity justifies a domain model then I would advise against using a code generator. Properly modeling the reality of a complex domain is not an easy task, and certainly not one that could be achieved by a tool.
I really like where symfony 2 is headed, I just really dont like doctrine, I love codeigniters active record db system, is there anyway I can completely remove doctrine from symfony and replace it with a DAL like of codeigniters ?
Doctrine 2 is a pure Data Mapper pattern implementation. Its advantage over Active Record is that you don't have to bend your model to a database schema or vice versa. In most cases your model and schema may evolve separately; you'll need to update the mapping metadata only.
Plus you don't have to extend/implement any special classes/interfaces. Your model consists of POPOs (Plain Old PHP Objects) and the mapping is managed by an external object — an entity manager. This allows for good OO design on the PHP side and good schema design on the database side.
So, I suggest you rethink your desire to go back to Active Record. It may take some time for the paradigm shift but it's worth it.
The thing that Doctrine is a default choice doesn't mean it's the only one. It's not tightly coupled to Symfony and can be replaced.
Symfony provides sensible defaults but gives you the freedom to change them.
For example, you might use Propel. It implements Active Record (as opposed to Doctrine2).
You can write your own ORM implementation if you'd like to.
Note that apart from ORM, Doctrine has some useful helper libraries. For example annotation reader is used in Symfony to parse annotations. If you use them you'll need this part of Doctrine.
I'm not sure how to put that question. It's a bit fuzzy, but if you encountered the Corpus Delicti, you'll know what I mean.
When I first came across how Symfony2 maps bundles onto paths, few days ago, I already felt bit puzzled about why they chose to map a Bundle name of
AxxBxxBundle onto .../Axx/BxxBundle/...
To me this decision seems arbitrary and confusing, don't get me wrong this is not a serious obstacle and you get used to it within five minutes, but still I think it smells funny.
Now I just came across this quote in the Book:
BundleName:ControllerName:TemplateName
This is the logical name of the template, which is mapped to a
physical location using the following convention.
/path/to/BundleName/Resources/views/ControllerName/TemplateName
And this is wrong I think, there would have to be slash between Bundle and Name.
But this quote shows me that even in the inner Symfony2 circle some people don't find that intuitive.
So what is the "philosophy" bind this bundle thing and its mapping logic?
This doesn't exactly answer the question about the reasoning, but it provides some more information on the Bundle-topic. To get an answer on the why, you should perhaps contact Fabien Potencier who wrote the Symfony\Component\HttpKernel\Kernel class which relies on this convention.
Coming from Zend Framework, it's not that bad for me. All those classes start with Zend_ Thinking of it as the owner/creater's name makes it easier. In java most libraries start with com.foobar
Quoting Fabien: "Symfony2 relies on well-know design patterns, and best practices coming from the Java world."
Your statement does not really make sense or I'm missing your point:
And this is wrong I think, there would have to be slash between Bundle
and Name.
Did you mean: Between Acme and DemoBundle? It does feel like a duplication, but
Quoting Fabien: "A bundle is a structured set of files that implements a single feature and can be easily shared with other developers."
I can use a blog bundle from Acme, then I find a similar bundle from Emca. Most likely their bundles will have the same model&controller&route names. Using them both: this way nothing gets overridden using another library. So the first name for the creator/owner is to prevent duplication.
Since it's a pain to use, I always call mine My/DemoBundle for quicker use :p Or you can give it a custom name during the console bundle generation (if you don't like it)
Also:
All core bundles are treated the exact same as your bundles and
everything is a bundle. Bundles are easily portable and configurable.
They are really the key to Symfony2’s real power. A bundle can extend
another bundle. It can be distributed independently from it’s
application.
Since the web assets are in the bundle, I believe they managed to get it right. That will allow easy configuration and reusability, e.g. bigger (scope) improvements can be made to the symfony core without effecting your app.
In the recent spirit of isolating stuff and plugging it in via NuGet, does anyone have an idea about how you'd limit a dependency resolver to just one area in MVC3? It's easy enough to keep views and controllers limited to an area, but unless I'm not seeing an obvious hook, it looks like setting an IDependencyResolver is something that unavoidably has global scope. I'd like to limit it to just one area.
Any suggestions?
IDependencyResolver is global by design. If you want to vary behavior by area, you should look at the various *Activator types and interfaces that can make decisions based on context objects.
What specifically are you trying to do?
I would suggest using the Common Service Locator for this. Basically each area could setup up the CSL for their specific container.
You will probably need to create an adapter between the dependency resolver or forgo it altogether and strictly use the CSL.
In general I am not a proponent of using the CSL in a line of business app. It's intent is to make it easier for open source components that use DI (like MassTransit) easier to integrate into line of business apps. This might be an exception however.
Also, look into the mvccontrib portable areas. It's designed for this type of thing.
What you're trying to do sounds like a bad idea. The point of dependency injection is so you can isolate specific dependencies and not have your code care where they come from.
If you're trying to restrict some objects or classes to a certain MVC area, configure your dependency injector to call the proper ones at the right time.
Some more details about what you're trying to do will help generate better answers.
Im currently evaluating Drupal to see if we can use it to replace our framework. My problem is I have this legacy tables which I would want to try to reflect in Drupal. It involves a join table. There's quite a lot of this kind of relationship in our existing web app so I am looking for possible ways to solve it.
Thank you for your insight!
There are several ways to do this, and it's hard to know which is best with no context about what you're actually doing with the data, but here are some options:
One way to do this is to make a content type representing each table (using CCK) with the foreign keys represented by type-specific node reference fields. Doing everything as nodes gives you a bunch of prebuilt functionality around nodes, but has a bit of overhead you may want to avoid.
Another option is to leave your database just like it is now. Drupal can do direct database queries, or you can use Data to expose your tables to Views.
Another option, if those referenced tables really only have 1 non-ID field, is to do the project_companies_assignments as nodes and do the other 3 as taxonomies. But this won't work if those are really more complex entities, and wouldn't be very flexible if they might become more complex.
What about using hook_views_api and exposing your legacy tables in hook_views_data? i tried something like this myself - not sure if that is what you want...
try and let me know if that works for you.
http://drupalwalla.blogspot.com/2011/09/how-do-you-expose-your-legacy-database.html
Going with Views and CCK, optionally with the additional Data module has one huge disadvantage: it comes with complexity.
My preferred alternative, is to write your own module. Drupal offers little help wrt database abstraction, it comes not with a proper ORM or such. But with some simple CRUD functions for the data in the database, a few simple forms in front, and a menu-callback with some pages to present the data, you can -quite often- get your datamodel worked out much faster then going the route of the overly complex, often poorly documented CCK and views modules. KISS.