How to make concrete complex model logic using Symfony2 and Doctrine 2 and their Design Patterns?

Question

Problem of the concrete kind

I've an object A (an entity) that manipulates some companies (entity), companies can be linked together (if they have some common shareholder for example). I want A to be able to know wether or not a company C1 is linked with a company C2.

Feelings

Within my state of knowledge and habits, I think that there should be a method in the company Entity to tell wether or not it's connected with another one (point 1). Of courses I can do it by getting all the company connexions, and looking wether or not my company C2 is in there (point 2). But this is dirty, it means getting all dependencies for what reason ? Getting a boolean that could be retrieved easily from the database, I could think about making a function in the repository linked with the companies (point 3). But no, because nothing is available in the entities (either A or C1 and C2), light weight objects remember.

Argumentations

• Point 1 is based on the Single Responsibility Principle. Feel free to criticize that point. Since entity are supposed to embed the model logic, I think the isConnectedWith function should be right in the definition of the CompanyEntity. Please remember here that A is also an entity (so repository here too)
• Point 2 is a solution, it's good in one sense : it's the right way to do, if, that's a big if, what Doctrine is only simulating was true; if simply calling $object->connexions accessed to some objects collection that was already there, somewhere in the memory. But the truth is awful : it's not there, it lived the common bottleneck of our webapp : database.
• Point 3 I'm getting sick of that Data Mapper & Dependency Injection combo telling that your entities (and a bit repositories) should live only by themselves because they are the model logic. Maybe I'm terribly wrong on my understanding, but since everybody is telling it's a bad thing, I've completely dropped the idea of injecting helper or configuration in the entities.

Questions

How would you solved the problem maintaining integrity and performances and avoiding dirty workaround ? What points of my argumentations are bad ?

Answer 1

Let's analyze your points

Point 3

Point 3 isn't a solution at all! Who told that inject pretty much everything into entity isn't a good solution, is absolutely right. This is nearly a "standard-de-facto" of best practices of OO and pattern programming.
Entity is there only for represent an "object" (not in IT acception, of course!) so, property and accessor methods are the only things you have to include.
Think about a situation where you inject something that change could change with time (methods signature, methods return type or logic): in those case, you have to change entity itself for keep the things works together, but why you have to do this into entity, that isn't changed? Think deeply about it because is a good point of start for OO programming (not symfony2 or entity representation only!)

Point 2

Yes, you're right: why fetch from DB all entity or, if you write a "good" query, only entity you're searching for, if you'll never use it?
About this point you have to analyze somethings like:

• Have I to use this (or those) entities elsewhere, so fetch it could be good?
• Did I know that Doctrine2 will keep in memory where he fetches the objects(*)? That means, when you query (or ask) for the same object previously fetched, he returns to you the same instance of that object? So, no DB connections, no fecth, no heavyweight operations.

Point 1

Yes, this is a good point. You have to implement (in repository, of course!) a method like ->isThere() or something better (this is first name that came in mind).
With this method you can write your custom SQL (called D QL, where D stands for Doctrine) where you return only a flag or an intenger (obtained with COUNT(*) or aggregative functions alike).
For fetch not an ArrayCollection of entity but a scalar result, as the name suggest you, use $query->getSingleScalarResult();
I suppose that I would incline for this last solution.

Hope to had explained all well

(*) This is called identity map