Третий фактор, на мой взгляд самый важный: 80% утверждают что любят классическую музыку, но только, дайте боги, в 20% случаев это действительно так. Да и музыка классическая очень разная.
Кому-то нравится Мадонна, а кому-то подавай White Stripes. Через 100 лет это тоже будет классикой.
В результате у неискушенных и не должно быть желания остановиться и послушать. Будучи чуточку искушенным, я бы постоял повтыкал, но поить меня Шато Мутоном 1945 года — переводить продукт.
Давайте, перестанем себя обманывать.
С биткоином все очевидно же: разрешите биткоин и валюта в том виде, в котором она сейчас есть, будет не нужна. Да и взятки в биткоинах получать значительно удобнее, не знаю чо они.
Финансовым институтам нужно жить на что-то. Если студенты при оплате обучения перестанут платить через банк с комиссией, кто-то потеряет бизнес, а кто-то работу. Деньги буду поступать на счет не дни! Вы задумайтесь только. Инкассация будет не нужна. Крах просто.
Станки должны получать прибыль при печати денег. И еще 100500 примеров того, почему биткоин не выгоден.
Д и в общем никто не мешает пойти вам в магазин и купить золотой слиток. Никто не мешает пойти и купить брюлик.
Ну и конечно российские регуляторы и дальше будет затруднять работу со средствами вывода денег из страны.
Операции будут проще: за недельку-другую вам напечатают/выростят новый орган из ваших же тканей, заменят роботом.
Проще купить новый бентли, чем заправить старый.
Но это будет завтра, а сегодня нужно что-то уже работающее. Суточные операции в подгузниках это близко предел человеческих возможностей, имхо. Экономия хотя бы 10 минут, может спасти жизнь.
Турбобуст легко может прозевать и 104 градуса, потом роняет частоту, когда чувствует что не может стабилизировать. Получить 104 градуса легко в пике, пока вентиляторы не разогнались, с работающими вентиляторами сложно получить даже 90.
Не понимаю почему вы сделали такой вывод.
Добрая половина документов в проектах обычно AR классы. Но они делают свое AR-ное дело, абстрагируют меня от СУБД, хранят бизнес логику своего поведения. 2+2 все еще 4 для меня.
Подождите
В моем примере AR кладет в БД, и логика работы в БД там же. Но категорически нельзя Генератору светящихся лампочек просить AR что-то делать, но можно Генератор Светящихся Лампочек попросить Модель данных AR попросить что-то сделать.
Вы же предлагаете всю предметную область положить в AR, как быть с сущностями сервисами, которые не хранят свои данные в AR а являются сервисами?
Вот поэтому и получаются жирные модели, когда у нас юзер становится монстром делающим не свойственные ему вещи и отвечающим за не свойственные ему операции, никакой патерн не заставит и _не_заставляет_ меня это делать, и даже не рекомендует. Всему должна быть мера.
Не вижу никаких усложнений, одни упрощения.
Я не предлагаю вмешивать в AR Services.
AR занимается своими обязанностями. Все остальное занимается своим делом.
Всем добра и Single Responsibility.
У юзера есть метод withdraw, но на юзера нельзя возлагать обязанности соблюдения бизнес логики всей системы, это не его обязанности.
Снять деньги у юзера — не обязанность юзера, а обязанность сервиса банка. Причем банк как сущность может вообще не иметь AR сущностей.
И это не усложнение, это — напротив — упрощение, сегрегация интерфейсов проще, чем порождение франкенштейнов. Собственно и в реальном мире с реальной бизнес логикой пользователь не может снять деньги со своего счета непосредственно.
«An object that wraps a row in a database table or view, encapsulates the database access, and adds domain logic on that data.»
Я не вижу тут диррективы: «все должно быть так и только так», это пример
PaymentService
def withdraw(user, amount)
validate business logic here
user.withdraw!(amount)
end
end
PaymentService.withdraw(user, 10)
Вот я не знаю точно user.withdraw!(amount) — domain logic? помоему не очень но это AR
Логика доступа сохранена, не вижу противоречий
Погодите, нигде не же сказано, что бизнес логика должна быть реализована через AR?
Объект AR не должен знать как снимать деньги со счета, но он должен знать как аз balance вычесть 10.
И нет в этом ничего оригинального, на AR возложены конкретные узкие обязанности.
Я не люблю когда контроллеры выполняют действия над моделями, если они сложнее чем CRUD. В сложном случае, это не работа контроллеров. Стащили у питонистов form_objects, есть сервисы, есть куча всяких чужих паттернов, мы же не в вакууме?
Сталкивался, в детстве. Уже давно бизнес логика не хранится в моделях. Но статьи про «thin controllers fat models» продолжают выходить с завидной регулярностью — это саботаж!
Существует масса вещей которые в наглую нарушают христианство например. Конечно Фаулер молодец, да и вообще святой, с этим трудно спорить. Но есть десятки тысяч счастливых разработчиков использующих AR на успешных проектах.
Сценарии
Со сценаристами проблемы
С писателями трудности, но проблем нет
Экранизировать Принцев Эмбера — уже нет технических проблем, но очевидно нет хороших сценаристов
Был бы эпик не хуже, а то и лучше, Властелина Колец, причем у Желязны 12(13?) серий бы получилось для экранизации Принцев
Кому-то нравится Мадонна, а кому-то подавай White Stripes. Через 100 лет это тоже будет классикой.
В результате у неискушенных и не должно быть желания остановиться и послушать. Будучи чуточку искушенным, я бы постоял повтыкал, но поить меня Шато Мутоном 1945 года — переводить продукт.
Давайте, перестанем себя обманывать.
Финансовым институтам нужно жить на что-то. Если студенты при оплате обучения перестанут платить через банк с комиссией, кто-то потеряет бизнес, а кто-то работу. Деньги буду поступать на счет не дни! Вы задумайтесь только. Инкассация будет не нужна. Крах просто.
Станки должны получать прибыль при печати денег. И еще 100500 примеров того, почему биткоин не выгоден.
Д и в общем никто не мешает пойти вам в магазин и купить золотой слиток. Никто не мешает пойти и купить брюлик.
Ну и конечно российские регуляторы и дальше будет затруднять работу со средствами вывода денег из страны.
Проще купить новый бентли, чем заправить старый.
Но это будет завтра, а сегодня нужно что-то уже работающее. Суточные операции в подгузниках это близко предел человеческих возможностей, имхо. Экономия хотя бы 10 минут, может спасти жизнь.
Добрая половина документов в проектах обычно AR классы. Но они делают свое AR-ное дело, абстрагируют меня от СУБД, хранят бизнес логику своего поведения. 2+2 все еще 4 для меня.
А про экранизацию жаль, очень-очень, печалька.
В моем примере AR кладет в БД, и логика работы в БД там же. Но категорически нельзя Генератору светящихся лампочек просить AR что-то делать, но можно Генератор Светящихся Лампочек попросить Модель данных AR попросить что-то сделать.
Вы же предлагаете всю предметную область положить в AR, как быть с сущностями сервисами, которые не хранят свои данные в AR а являются сервисами?
Вот поэтому и получаются жирные модели, когда у нас юзер становится монстром делающим не свойственные ему вещи и отвечающим за не свойственные ему операции, никакой патерн не заставит и _не_заставляет_ меня это делать, и даже не рекомендует. Всему должна быть мера.
Я не предлагаю вмешивать в AR Services.
AR занимается своими обязанностями. Все остальное занимается своим делом.
Всем добра и Single Responsibility.
У юзера есть метод withdraw, но на юзера нельзя возлагать обязанности соблюдения бизнес логики всей системы, это не его обязанности.
Снять деньги у юзера — не обязанность юзера, а обязанность сервиса банка. Причем банк как сущность может вообще не иметь AR сущностей.
И это не усложнение, это — напротив — упрощение, сегрегация интерфейсов проще, чем порождение франкенштейнов. Собственно и в реальном мире с реальной бизнес логикой пользователь не может снять деньги со своего счета непосредственно.
Я не вижу тут диррективы: «все должно быть так и только так», это пример
PaymentService
def withdraw(user, amount)
validate business logic here
user.withdraw!(amount)
end
end
PaymentService.withdraw(user, 10)
Вот я не знаю точно user.withdraw!(amount) — domain logic? помоему не очень но это AR
Логика доступа сохранена, не вижу противоречий
Объект AR не должен знать как снимать деньги со счета, но он должен знать как аз balance вычесть 10.
И нет в этом ничего оригинального, на AR возложены конкретные узкие обязанности.
Ну и AR получился в Rails, 99% задач решаются через AR.
Со сценаристами проблемы
С писателями трудности, но проблем нет
Экранизировать Принцев Эмбера — уже нет технических проблем, но очевидно нет хороших сценаристов
Был бы эпик не хуже, а то и лучше, Властелина Колец, причем у Желязны 12(13?) серий бы получилось для экранизации Принцев