какая разница умирает он или нет?

в java имеет смысл в том случае что не надо перечитывать конфигурацию

и что одну сущность можно передавать

в java имеет смысл в том случае что не надо перечитывать конфигурацию

у доктрины есть кеш

да и какая разница

суть не в этом же

в том что независишь от бд

представил проект где каждый день меняется бд

в том что независишь от бд

а с доктриной не так?

так же как и с хибернейтом, пока ты не зависишь от БД ты не зависишь от БД)

вопрос в том надо ли это ?

вопрос в том надо ли это ?

ну.... мне удобненько

приложению прямо 100% не зависить

приложению прямо 100% не зависить

погоди, суть не в этом

суть не втом, что можно менять

суть в том что бы бизнес логика не зависила

а не приложение

да

и это достигается

а в том, что можно логику и работу с хранилищем хранить отдельно

а значит и тестировать

doctrine Это magic mapper

и в случае нагрузок оптимизировать независимо

я знаю зачем доктрина)

и hibernate

doctrine Это magic mapper

магии там много, не спорим, но в целом норм)

я знаю зачем доктрина)

и зачем?)

в 2 словах

если больше двух слов - то уже сомнительно

в 2 словах

за-тем)

object relation mapper

там 3 слова

object relation mapper

нет, это не цель доктрины. Для этого есть более простые решения

persistence ignorance

вот эти два слова

в том чтобы данные хранящиеся в реляционном виде (БД) преобразовывать в объектный и наоборот

в том чтобы данные хранящиеся в реляционном виде (БД) преобразовывать в объектный и наоборот

опять же нет, проще тогда взять любую документно-ориентированную базу и вообще не напрягаться с мэппингами

или active record )

завернуть что бы получился row data gateway и норм

ar сильно завязано на структуру бд

ar сильно завязано на структуру бд

какая разница если ar это тупо модель данных?)

как раз таки ей и положено

модель зависящая от хранения

ты можешь бизнес логику вынести в доменную сущность которая будет хранить данные внутри ar моделек

модель зависящая от хранения

модель данных

ок )

class User { /** * @var UserDataModel */ private $userData; }

вот о чем я

> Или, можно взять все, что есть в языке и назвать это объектами как по мне это более чем валидно

это ли имел ввиду Алан Кей?)

но просто вроде все ок с таким подходом и хаскель тогда один из самых ОО языков программирования)

это ли имел ввиду Алан Кей?)

не уверен... он точно говорил что "но я не имел ввиду C++"

вообщем ООП головного мозга наверно также плохо как и ФП головного мозга и подобного)

но просто вроде все ок с таким подходом и хаскель тогда один из самых ОО языков программирования)

Об этом Вэст вещает в своих речах... мол что ФП это просто очередной виток очевидной идеи об изоляции побочных эффектов

тип тренд ФП с монадами и т.д. это лишь повторение того что подразумевалось под ооп

вообщем ООП головного мозга наверно также плохо как и ФП головного мозга и подобного)

почитай письмо Дэйкстры

что бы понять предпосылки появления всего этого булшита

то самое которое goto considered harmful

что именно Дэйкстры почитать

мне нравиться как он пишет он норм мужик)

http://david.tribble.com/text/goto.html

вот тут с пояснениями и разбором мыслей

это про ненависть к goto ?

это объяснение проблемы с goto

про сложность верификации такой программы

у меня где то перевод избранных статей его лежит

это про ненависть к goto ?

Here Dijkstra observes that humans are better at visualizing static relationships than dynamic relationships. Thus, he argues, we should minimize the difference between the two when expressed as program code, so that the dynamic (nonconstant) aspects of the program are evident in the structure of the source code itself.

даже поставлено todo чтобы их прочитать как время будет)

ERROR: S client not available

http://david.tribble.com/text/goto.html

только это какой-то дискашен на тему

вот например одна из основных мыслей которые заставили меня сильно много думать

http://david.tribble.com/text/goto.html

блин, крутой разбор, я только оригинальное письмо читал и немного срачей на тему

блин, крутой разбор, я только оригинальное письмо читал и немного срачей на тему

хм, а что может быть интересного в том что гото гавно?) вроде же это аксиома, давно же решили так умные дядьки

хм, а что может быть интересного в том что гото гавно?) вроде же это аксиома, давно же решили так умные дядьки

То, что это не аксиома?

То, что это не аксиома?

ну я хотел сказать, что гото это же что-то мертвое, с чем никогда не встретишься

ну я хотел сказать, что гото это же что-то мертвое, с чем никогда не встретишься

И почему так?

И почему так?

ну я не говорю, что плохо это читать, просто интересуюсь, какой с этого профит? Скажем так, меня это удивило. А плохо, никогда не думал на эту тему, но наверно потому, что несёт путаницу.

ну я не говорю, что плохо это читать, просто интересуюсь, какой с этого профит? Скажем так, меня это удивило. А плохо, никогда не думал на эту тему, но наверно потому, что несёт путаницу.

ОО возникло не на пустом месте, всему были причины.

Их понимать надо для того, чтобы яснее понимать принципы, когда что-то стоит делать, а когда не стоит

scala норм, если проникнуться... но мне больше kotlin нравится

котлин, да, он дружелюбнее как-то

Их понимать надо для того, чтобы яснее понимать принципы, когда что-то стоит делать, а когда не стоит

вот и ответ на мой вопрос, спасибо

ну я не говорю, что плохо это читать, просто интересуюсь, какой с этого профит? Скажем так, меня это удивило. А плохо, никогда не думал на эту тему, но наверно потому, что несёт путаницу.

интересный факт. То письмо не совсем про goto

ну тоесть 90% информации описывает почему вообще такие штуки не очень хорошо. Не конкретно goto а почему вообще нам надо писать код по другому. ПОнимание этого позволит тебе лучше понять себя.

а можно просто писать на битриксе и не забивать голову всякими умными словами

а можно просто писать на битриксе и не забивать голову всякими умными словами

можно, но это потолок

насколько бредовой выглядит идея сделать все модели immutable? а сеттеры заменить на что-то вроде withProperty('new value'): self

@fes0r Сергей ^

насколько бредовой выглядит идея сделать все модели immutable? а сеттеры заменить на что-то вроде withProperty('new value'): self

хм, а что это хорошего даст в данном случае?

не знаю. пытаюсь понять возможные последствия для архитектуры

Сеттеры или их замена плохо)

я почитал про CQRS у Фаулера

вроде как это связанные вещи

Именно так и выглядят ValueObjects

но все равно не понятн

имхо это может дать плюсы в много поточной среде

я почитал про CQRS у Фаулера

в моем понимании оно про то, что в некоторых случаях (ээээ "доменах предметной области") отображение/чтение и изменение данных происходят существенно разным образом. в С++ к примеру у каждого класса потенциально имеется ДВА интерфейса - для чтения и для записи.

где хорошо чтобы все было имутабельно

в случае с пхп большого профита врятли стоит ожидать

имхо это может дать плюсы в много поточной среде

у меня нет многопоточности, я говнокодер на пхп

я написал имхо

с точки зрения "модель только для чтения" - это immutable модель