Что ты имеешь в виду под entity в симфони — привязанную к базе данных модель? Репозиторий — это в смысле менеджер? Спокойно можно обратиться.

https://docs.djangoproject.com/en/dev/topics/db/queries/#retrieving-objects — как обратиться к репозиторию.

Смысл: репозиторий работает на уровне таблицы в ORM, а сущность — на уровне одной строки в этой таблице.

«Смысл: репозиторий работает на уровне таблицы в ORM, а сущность — на уровне одной строки в этой таблице.» Но ведь можно было сделать статические методы для обращения к таблице и нестатические для обращения к конкретноу сущности.

Зачем здесь надо было репозитории придумывать?

Эмм. Получить все сущности [удовлетворяющие заданному условию] — это, например, задача уровня репозитория и этим занимается дефолтный репозиторий. https://docs.djangoproject.com/en/dev/topics/db/managers/#django.db.models.Ma... — что ещё можно с ними делать (в случае джанги, в симфони я хуже).

For example, this custom Manager offers a method with_counts(), which returns a list of all OpinionPoll objects, each with an extra num_responses attribute that is the result of an aggregate query

оно добавляет лишний атрибут в entity.

Только попробуй сказать, что это — задача уровня entity, а не репозитория. Хотя я не знаю, как именно в symfony это делается.

«Только попробуй сказать, что это — задача уровня entity, а не репозитория»

Плохой аргумент. Кто так считает еретики и разговаривать не о чем. Даже если это и так то непонятно в чем причина.

Твою ссылку изучу. за нее спасибо

В джанге можно взять одну и ту же entity и одновременно использовать с ней несколько разных репозиториев. Дефолтный (objects) — особо не отличается от стандартных репозиториев в symfony, недефолтные — могут добавлять разные поля (как выше) либо выдавать вообще что угодно вместо набора сущностей. Как именно это реализовано в symfony — не представляю, но, судя по докам, там дела обстоят примерно так же: можно создавать кастомные репозитории, делающие другие запросы.

Давай так у нас есть класс — ему соответсвует сущность (Соответствует ли ему таблица?) Далее у нас есть экземляр класса — эекземляр сущности. Запись преобразованная в объект.

Репозиторий — на уровне базы данных это что? Или на уровне бызы репозитория вообще не существует?

Да и вообще что такое «репозиторий» абстрактный в вакууме?

Если репозиторий есть некая абстракция независящая от таблицы то зачем она нужна?

«ДОбавлять поля» смотрю что на примерах по джанге в модели описаны поля, а не геттеры и сеттеры.

Если описывать геттеры и сеттеры то дополнительные поля легко выносятся на уровеь сущности. Правильно это или нет не берусь утверждать.

Репозиторий — это магия, умеющая доставать сущности из базы (ну или не сущности, если хочешь этого).

Соответствует ли ему таблица?

Нет. Тем более что класс может быть размазан по тонне таблиц либо вообще не храниться там.

Репозиторий — на уровне базы данных это что?

Это интерфейс, через который проводятся запросы к БД. На уровне БД его нет. Дефолтный делает select whatever from whattable where whatcondition; опционально — с объединениями и прочим.

Наверно, этой ссылкой можно было закрыть тред.

Но ведь можно было сделать статические методы для обращения к таблице и нестатические для обращения к конкретноу сущности.

http://www.b-list.org/weblog/2008/feb/25/managers/

But there are two much larger benefits from having these methods on a separate class:

It opens up the ability to define multiple sets of query behaviors, and choose between them as needed. So, for example, the Entry class might get two managers: one which queries on all entries, for use in the admin interface, and another which only queries on entries with is_live=True for public views. It provides an easy way to encapsulate patterns of behavior; if you commonly need to have a set of extra query methods, for example, or want to change the behavior of existing methods, you only need to write that code once — in a Manager subclass — and can reuse it on multiple models, rather than having to duplicate the logic every time you want to use it.

и http://stackoverflow.com/q/7692487/2815355 если мало.

Если описывать геттеры и сеттеры то дополнительные поля легко выносятся на уровеь сущности.

В питоне пофиг, т.к. геттеры/сеттеры там тоже прикидываются полями через @property.

http://thinkbeforecoding.com/post/2009/03/04/How-not-to-inject-services-in-en...

http://stackoverflow.com/questions/5694241/ddd-the-rule-that-entities-cant-ac...

Похоже это один из принципов Domain Driven Development. Наверное оттуда и ноги растут.