I'm using symfony 2.4 and doctrine, I have struggled coming up with the right mapping for relations in my entities classes.
Question: Do I really have to do it? Or can I just use joins in my repositories classes? I feel more comfortable with the latter, are there any drawbacks if just use joins?
Answer: if you don't wont to do it why do you use doctrine? It's really powerful tool and in my opinion, one of the most important part of this library.
If you need help with defining relations please don't hesitate to put a short code here. We can find a solution. In the beginning it's always hard to understand, but after creating a very first well mapped entities it becomes to be pretty clear how and why to do that.
It's of course possible to avoid defining relations, but after-effects will be painful.
Related
I had to manage relationships between documents over a NoSQL engine (Couchbase), and I figured out this way to solve my problem. Here is my solution and the steps that let me realize it:
https://forums.couchbase.com/t/document-relationships-using-arrays-and-views-passing-though-graph-theory/3281
My questions are:
What do you think about this solution?
Have you ever used something like this? How is it working?
Are there any better ideas? Critical points of this solution should be helpful
Thank you.
Interesting post Matteo. After reading it I realized that you can possibly improve on few aspects:
Consider 1-1 node relationships. In your post you focus on N-N node
relationships (sure one can argue that 1-1 is a subset of
N-N)...however I think there is a potential of having a different (optimized) implememgtaion for 1-1 relationships. for 1-1 I use node key
value as a field in my json doc (e.g. user: {name:string, dob:date,
addressID:string})
Node key design to address relationships: You can encode in the key
value relationship information, e.g. key: "user#11", "user#11#address#123", "address#123#user#11", etc.
Data integrity aspects: Take into consideration missing complex
transactions. i.e. you can't mutate several documents in one
transaction. The design should compensate for that.
I have used similar solution in my model design for Couchbase in the past. Its now in production for several years already and its performing just fine (load is about 250 tps)...I was trying to avoid as much as possible creating complex node relations and ended up having very few 1-1 and 1-N types.
I tested out this solutions and works well. I like the flexibility of the 'always possible' N-N relationships, because you can simply add the relationship document when you need it without changing the application logic. There is a drawback: you need to implement your own application logic constraints to avoid relationships abuse.
I noticed that using arrays there isn't a great advantage compared to JSON objects and sometimes it may be useful to have other relationships data, for example the weight (or cost) of the relationship. So I suggest you to use a relationship document that as it's own type:
{
"type": "relationship",
"documents": ["key1", "key2"],
"all-the-data-you-need": { ... }
}
Looking at the performance there isn't so much difference using objects over arrays.
Hope this helps someone! ;)
I just want to know what are advantages/drawback of a bidirectional relation in Doctrine with Symfony ?
All my relations are bidirectional, but I'm not sure if this will not cause a problem...
Thanks.
As long as you don't mark relations as EAGER I think you're good. to go.
However, there is a small overhead since PHP has to, at least, create Proxy instances. Beware of this if you plan on serializing objects. Some serialization mechanism are programmed to resolve (load) proxy if they hit one. That would mean an extra round-trip to database server.
Bottom line: As you develop your model, ask yourself "Do I really need this?". It's super easy to add it later if you find yourself in that situation. Also, when it comes to OneToMany and ManyToOne, pay special attention to owning/inverse side concepts as it could introduce a number of WTFs/minute :)
Hope this helps you a bit...
I like EF but poco classes with attributes still seem like they are too tightly coupled to the framework. If I want to use those same Poco classes for something other than EF those attributes may have no use or meaning.
Is there a way to deal with this?
Your POCO won't be tightly coupled anymore if you switch from Data Annotations the Fluent API.
Have a look at this SO aswer where I explained how to proceed.
Yes what you are looking for is modelbuilder configuration. This leaves all entites completely POCO. Check out my blog article here as a bit of a starting point http://blog.staticvoid.co.nz/2012/7/17/entity_framework-navigation_property_basics_with_code_first in the second half of the article i discuss some of the basics of the modelbuilder. There are plenty of more specific tutorials on the modelbuilder and how to use it online
Getting data from a database table to an object in code has always seemed like mundane code. There are two ways I have found to do it:
have a code generator that reads a database table and creates the
class and controller to map the datafields to the class fields or
use reflection to take the database field and find it on the class.
The problems noted with the above 2 methods are as noted below
Method 1 seems to me like I'm missing something because I have to create a controller for every table.
Method 2 seems to be too labor intensive once you get into heavy data
access code.
Is there a third route that I should try to get data from a database onto my objects?
You normally use OR (Object-Relational) mappers in such situations. A good framework providing OR functionality is Hibernate. Does this answer your question?
I think the answer to this depends on the available technologies for the language you are going to use.
I for one am very successful with the use of an ORM (NHibernate) so naturally I may recommend option one.
There are other options that you may wish to take though:
If you are using .NET, you may opt to use attributes for your class properties to serve either as a mapping within a class, or as data that can be reflected
If you are using .NET, Fluent NHibernate will make it quite easy to make type-safe mappings within your code.
You can use generics so that you will not need to make a controller for every table, although I admit that it will be likely that you will do the latter anyway. However the generics can contain most of the general CRUD methods that is common to all tables, and you will only need to code specific quirks.
I use reflection to map data back and forth and it works well even under heavy data access. The "third route" is to do everything by hand, which may be faster to run but really slow to write.
I agree with lewap, an ORM (object-relational mapper) really helps in these situations. You may also want to consider the Active Record pattern (discussed in Fowler's Patterns of Enterprise Architecture book). It can really speed up creation of the DAL in simple apps.
I have looked at NHibernate and EntitySpaces and they both seem to work differently.
In EntitySpaces, you define the database tables and table relationships and the classes are generated for you.
In NHibernate, you define the classes and the table relationships are generated for you. This is what I am looking for.
Are there any other ASP.NET ORMs that generate tables from classes like NHibernate?
Any recommendations?
DataObjects.Net also uses "Code first" (Model first) approach.
See http://wiki.dataobjects.net/index.php?title=Features
Linq to SQL can create the database table structures and relationships from the classes, with the dataContext.CreateDatabase() method.
Mindscape LightSpeed offers this ability - part of complete scheme round-tripping.
Hope this helps
http://www.mindscape.co.nz/blog/index.php/2008/06/17/schema-round-tripping-in-the-lightspeed-designer/
I prefer an approach that I have full control to generate what I need as well. In the case of ORMs I get classes that match my tables. I believe that using my own domain of objects that derives from my business and not the underlying data store is the right way to go. My class hierarchies that represent my business data should be 100% independent from the data store.
LightSpeed has a really good Visual Studio designer that supports both generating .NET entity classes from the database and updating the database from your .NET entities.
This is something that NHibernate does.
And on the subject (that Draemon) started. My personal view is that unless performance is your absolute 1st priority and all other things must suffer to make that happen (e.g. when writing software for a manufacturing fab), you will be better off working on the domain model first.
My reasoning: you spend a lot more time coding against the domain than you do against the database itself -- especially when using an orm. So spend that time wisely.
I had fairly good success working with Genome ORM. It does many jobs for you. You can first design your domain model and then generate the DB scripts out of that. Beside this Genome generates DTOs for you. It is pretty good at that and saves a lot of time of developers.
http://www.genom-e.com