Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>ER-содель — это когда только сущность и атрибуты. Появляются методы, она уже перестает быть ER. G>>По каким причинам они могут там появиться не нарушая SRP и другие принципы хорошего дизайна? T>По той причине, чтобы не дать перевести сущность/модель в невалидное состояние. Я же об этом уже писал.
Да пусть будет в невалидном состоянии, главное чтобы сущность не была сохранена в невалидном состоянии. Но это обеспечивается другими средствами.
G>>Например какие методы могут появиться у location, ну кроме переопределения Equals и ToString? T>Ну например, при закрытии location-а equipment, расположеный в этом location-е должен быть переведен в статус "неактивный". T>Как мне соблюсти это правило, если всем доступны напрямую все сущности (как в er-модели)?
service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
Здравствуйте, gandjustas, Вы писали:
T>>Я не считаю, что сложность уменьшилась. Меньшее кол-во строчек еще не показатель. G>Еще как уменьшилась. G>1)Структурированность кода стала выше, в сами ифы стало невозможно дописывать G>2)Из-за сокращения объема кода он стал нашляднее, проще читать, следовательно меньше ошибок будет допущено, быстрее они будут выявлены. G>3)Стало невозможно допустить ошибку недописывания else перед новым if при добавлении условия
Но не забывай, что все это путем усложнения сруктуры класса — разные action-ы пришлось вынести в отдельные методы.
G>Кроме того появилась дополнительная гибкость — появилась возможность формировать таблицу действий в run-time.
А оно надо?
G>Почитайте книгу "жемчужины программирования", так описаны такие преобразования.
Я тебе это преобразование 5 минут назад запостил. Ты считаешь я его не знаю.
T>>Кроме того, в код внесена ошибка. G>какая?
Найди.
T>>Цель примера была не в том, чтобы доказать, что всегда есть способ облапошить комплексити, а в том, что такие ситуации встречаются и уже на этом основании нельзя особо полагаться на этот показатель. G>Вы доказали что качество кода состоит не только из CyclomaticComplexity, а из многих составляющих. Но это и так известно.
Я показал, что один из коэффициентов, входящий MaintainabilyIndex вполне может быть обманут. А следовательно и сам index под подозрением.
G>>>Вот если у вас предикат одинаковый, а параметры разные, то это можно свести к таблице или паттернам состояние\стратегия. T>>И ты считаешь, что это проще? Вместе нескольких if-ов генерить интерфес стратегии + классы реализующие интерфейс. G>Если это код, подверженный частым изменениям, то проще. Иначе можно ограничиться таблицей.
Кому как, а по-моему это явный overdesign — когда простой if заменяется на непойми что.
Здравствуйте, gandjustas, Вы писали:
T>>По той причине, чтобы не дать перевести сущность/модель в невалидное состояние. Я же об этом уже писал. G>Да пусть будет в невалидном состоянии, главное чтобы сущность не была сохранена в невалидном состоянии. Но это обеспечивается другими средствами.
Какими?
T>>Ну например, при закрытии location-а equipment, расположеный в этом location-е должен быть переведен в статус "неактивный". T>>Как мне соблюсти это правило, если всем доступны напрямую все сущности (как в er-модели)?
G>service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
Зато данные не защищены от поломки из других сервисов
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>Где-то еще — это где? Я предполагал, что у кастомера и так есть страна. Тогда получить валидацию можно так: T>
Вместо кастомера можно ченить еще придумать, где параметр валидации не находися в самой сущности.
G>>Это значит маппер должен уметь инжектить переданный ему инстанс стратегии в создаваемую сущность. С другой стороны при ручном создании инстанса надо инжектить такуюже стратегию. G>>Учитывая что не все мапперы позволяют перехватывать процесс создания объектов получается не очень хорошо.
T>А теперь рассказывай, как ты будешь с этим бороться:
T>
T>update customer set zipCode = "любой невалидный zip";
T>
С этим вообще никак нельзя бороться, если кто угодно может получить доступ к базе, то смысла нет городить валидацию в приложении. Но это вопрос администрирования.
Здравствуйте, gandjustas, Вы писали:
T>>Где-то еще — это где? Я предполагал, что у кастомера и так есть страна. Тогда получить валидацию можно так: T>>
G>Вместо кастомера можно ченить еще придумать, где параметр валидации не находися в самой сущности.
Нпример?
T>>А теперь рассказывай, как ты будешь с этим бороться:
T>>
T>>update customer set zipCode = "любой невалидный zip";
T>>
G>С этим вообще никак нельзя бороться, если кто угодно может получить доступ к базе, то смысла нет городить валидацию в приложении. Но это вопрос администрирования.
Я имею в виду если кто-то выставит невалидный zip в приложении и сасабмитит в базу.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Причем тут хранилище? Сущности ортогональны хранилищу. T>>>Нет, сущность не ортогонально зхранилищу, т.к. именно хранилище определяет что именно, какие атрибуты у нас в сущности. G>>Если храним в XML, то одни атрибуты, а если храним в БД, то другие?
T>Кончай уже. Если у тебя er, то как тебе это поможет?
Я смысл фразы "сущность не ортогонально зхранилищу" пытаюсь понять.
G>>Простой пример. Есть бизнес-правило, что ЗП сотридника не должна быть меньше МРОТ. Был у нас МРОТ 2000 рублей и были сотрудники с ЗП 2500, тут МРОТ увеличили до 4000 рублей. Если мы оформляем бизнес-правило как инвариант сущности, то становится все плохо, сотрудник с ЗП ниже 4000 даже не может быть считан из базы, возникнет ошибка и исравить её можно только прямой правкой данных в базе.
T>Нет, не так. Инвариант будет несколько сложнее: МРОТ не существует один раз на веки вечные. Это некоторый закон, который начинает действовать с какого-то времени и теряет силу после того, как принят следующий мрот. Поэтому если уж ты проверяешь инвариант при загрузке сущности (кстати, зачем?), то ты должен взять последнюю дату модификации зарплаты и удостовериться, что зарплата не меньше значения, установленного законодательством не тот момент.
То есть нам еще надо будет хранить сведения об истории изменения МРОТ, при каждом измении ЗП и лезть в базу за проверкой значения МРОТ...
Вот и проблемы Domain Model на лице, нереальное стремление к тяжеловесности решений. Это даже фаулер в своей книге упоминает, но как-то всколзь, как-будто это нормально.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Я не считаю, что сложность уменьшилась. Меньшее кол-во строчек еще не показатель. G>>Еще как уменьшилась. G>>1)Структурированность кода стала выше, в сами ифы стало невозможно дописывать G>>2)Из-за сокращения объема кода он стал нашляднее, проще читать, следовательно меньше ошибок будет допущено, быстрее они будут выявлены. G>>3)Стало невозможно допустить ошибку недописывания else перед новым if при добавлении условия
T>Но не забывай, что все это путем усложнения сруктуры класса — разные action-ы пришлось вынести в отдельные методы.
Это разве плохо? Обычно считается что разные методы (особенно небольшие) — это замечательно.
G>>Кроме того появилась дополнительная гибкость — появилась возможность формировать таблицу действий в run-time. T>А оно надо?
А кто знает, может и надо. Любой код стоит рассматривать с точки зрения дальнейшиго расширения.
T>>>Цель примера была не в том, чтобы доказать, что всегда есть способ облапошить комплексити, а в том, что такие ситуации встречаются и уже на этом основании нельзя особо полагаться на этот показатель. G>>Вы доказали что качество кода состоит не только из CyclomaticComplexity, а из многих составляющих. Но это и так известно.
T>Я показал, что один из коэффициентов, входящий MaintainabilyIndex вполне может быть обманут. А следовательно и сам index под подозрением.
Чем обманут? в приведенных примерах CyclomaticComplexity снижался, но снижения одного мараметра в маленьком куске кода на сложность проекта вообще не влияет. MaintainabilyIndex работает для больших кусков. Я об этом писал.
G>>>>Вот если у вас предикат одинаковый, а параметры разные, то это можно свести к таблице или паттернам состояние\стратегия. T>>>И ты считаешь, что это проще? Вместе нескольких if-ов генерить интерфес стратегии + классы реализующие интерфейс. G>>Если это код, подверженный частым изменениям, то проще. Иначе можно ограничиться таблицей.
T>Кому как, а по-моему это явный overdesign — когда простой if заменяется на непойми что.
Любой код стоит рассматривать с точки зрения дальнейшиго расширения.
А вы только АКПП Фаулера читали? Еще Рефакторинг почитайте, там один из первых примеров как раз такой.
Здравствуйте, gandjustas, Вы писали:
T>>Кончай уже. Если у тебя er, то как тебе это поможет? G>Я смысл фразы "сущность не ортогонально зхранилищу" пытаюсь понять.
Хранилище — это это нечто, хранящее структурированные дынные. Для того, чтобы из хранилища можно было восстановить сущность нужно иметь некоторый маппинг из "полей" хранилища в поля "сущности". Хотя бы по этому показателю они зависимы, а следовательно ортогональными их нельзя считать.
T>>Нет, не так. Инвариант будет несколько сложнее: МРОТ не существует один раз на веки вечные. Это некоторый закон, который начинает действовать с какого-то времени и теряет силу после того, как принят следующий мрот. Поэтому если уж ты проверяешь инвариант при загрузке сущности (кстати, зачем?), то ты должен взять последнюю дату модификации зарплаты и удостовериться, что зарплата не меньше значения, установленного законодательством не тот момент. G>То есть нам еще надо будет хранить сведения об истории изменения МРОТ, при каждом измении ЗП и лезть в базу за проверкой значения МРОТ...
Конечно. Так и делают. Закон редко когда вступает в силу с момента публикации, как правило отдельно оговаривается с какой даты в будущем он начинает действовать.
G>Вот и проблемы Domain Model на лице, нереальное стремление к тяжеловесности решений. Это даже фаулер в своей книге упоминает, но как-то всколзь, как-будто это нормально.
Это не сложность привнесенная domain model, а сложность предметной области. В er тебе тоже пришлось бы хранить этот инвариант в том или ином виде.
P.S. Кстати, а зачем тебе валидировать сущность при загрузке?
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>По той причине, чтобы не дать перевести сущность/модель в невалидное состояние. Я же об этом уже писал. G>>Да пусть будет в невалидном состоянии, главное чтобы сущность не была сохранена в невалидном состоянии. Но это обеспечивается другими средствами. T>Какими?
Тойже валидацией, бизнес-правилами и прочим. Только она будет вне кода сущностей, в идеале задана декларативно и вызываться при сохранении.
T>>>Ну например, при закрытии location-а equipment, расположеный в этом location-е должен быть переведен в статус "неактивный". T>>>Как мне соблюсти это правило, если всем доступны напрямую все сущности (как в er-модели)?
G>>service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
T>Зато данные не защищены от поломки из других сервисов
Для проверки такого есть тесты.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Где-то еще — это где? Я предполагал, что у кастомера и так есть страна. Тогда получить валидацию можно так: T>>>
G>>Вместо кастомера можно ченить еще придумать, где параметр валидации не находися в самой сущности. T>Нпример?
Просто представьте что такой кастомер.
T>>>А теперь рассказывай, как ты будешь с этим бороться:
T>>>
T>>>update customer set zipCode = "любой невалидный zip";
T>>>
G>>С этим вообще никак нельзя бороться, если кто угодно может получить доступ к базе, то смысла нет городить валидацию в приложении. Но это вопрос администрирования.
T>Я имею в виду если кто-то выставит невалидный zip в приложении и сасабмитит в базу.
1)в приложении все подряд не могут сабмитить в базу.
2)Есть тесты, которые проверят правильность работы логики
3)Саму валидацию на всех уровнях никто не отменял, но она содержится не классах сущностей, а вне их.
Здравствуйте, gandjustas, Вы писали:
G>>>1)Структурированность кода стала выше, в сами ифы стало невозможно дописывать G>>>2)Из-за сокращения объема кода он стал нашляднее, проще читать, следовательно меньше ошибок будет допущено, быстрее они будут выявлены. G>>>3)Стало невозможно допустить ошибку недописывания else перед новым if при добавлении условия
T>>Но не забывай, что все это путем усложнения сруктуры класса — разные action-ы пришлось вынести в отдельные методы. G>Это разве плохо? Обычно считается что разные методы (особенно небольшие) — это замечательно.
Все хорошо в меру.
G>>>Кроме того появилась дополнительная гибкость — появилась возможность формировать таблицу действий в run-time. T>>А оно надо? G>А кто знает, может и надо. Любой код стоит рассматривать с точки зрения дальнейшиго расширения.
Этот вопрос заслуживает отдельного флейма. Давай не будем.
T>>Я показал, что один из коэффициентов, входящий MaintainabilyIndex вполне может быть обманут. А следовательно и сам index под подозрением. G>Чем обманут? в приведенных примерах CyclomaticComplexity снижался, но снижения одного мараметра в маленьком куске кода на сложность проекта вообще не влияет. MaintainabilyIndex работает для больших кусков. Я об этом писал.
Размер тут большого значения не имеет. Смогли скомпрометировать в одном месте, сможем и везде.
T>>Кому как, а по-моему это явный overdesign — когда простой if заменяется на непойми что. G>Любой код стоит рассматривать с точки зрения дальнейшиго расширения. G>А вы только АКПП Фаулера читали? Еще Рефакторинг почитайте, там один из первых примеров как раз такой.
Спасибо за заботу, но я его уже читал лет этак 5 назад.
Здравствуйте, gandjustas, Вы писали:
T>>>>По той причине, чтобы не дать перевести сущность/модель в невалидное состояние. Я же об этом уже писал. G>>>Да пусть будет в невалидном состоянии, главное чтобы сущность не была сохранена в невалидном состоянии. Но это обеспечивается другими средствами. T>>Какими? G>Тойже валидацией, бизнес-правилами и прочим. Только она будет вне кода сущностей, в идеале задана декларативно и вызываться при сохранении.
Как она будет вызываться? Если какой-то сервис не станет ее вызывать, получим невалидные данные?
G>>>service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
T>>Зато данные не защищены от поломки из других сервисов G>Для проверки такого есть тесты.
Если автор не захотел писать тест или автор — третье лицо, то смиримся с тем, что данные могут поломать?
Здравствуйте, Tissot, Вы писали:
T>>>Я показал, что один из коэффициентов, входящий MaintainabilyIndex вполне может быть обманут. А следовательно и сам index под подозрением. G>>Чем обманут? в приведенных примерах CyclomaticComplexity снижался, но снижения одного мараметра в маленьком куске кода на сложность проекта вообще не влияет. MaintainabilyIndex работает для больших кусков. Я об этом писал.
T>Размер тут большого значения не имеет. Смогли скомпрометировать в одном месте, сможем и везде.
А кто-то говорил про универсальность MaintainabilyIndex? Смотреть MaintainabilyIndex для частей проекта (классов, методов) полезно только для определения что влияет на индекс. Само значение индекса для одного класса\метода смысла практически не имеет.
Например запихнув все в один класс (domain model и active record) вы получите в этом классе маленький MaintainabilyIndex, но вам придется немало кода написать чтобы маппер инжектил все параметры в такой класс что сильно негативно повлияет на MaintainabilyIndex всего проекта.
Здравствуйте, gandjustas, Вы писали:
G>>>Вместо кастомера можно ченить еще придумать, где параметр валидации не находися в самой сущности. T>>Нпример? G>Просто представьте что такой кастомер.
Какой такой? Если есть страна, то она где-то хранится. Следовательно её всегда можно узнать.
G>>>С этим вообще никак нельзя бороться, если кто угодно может получить доступ к базе, то смысла нет городить валидацию в приложении. Но это вопрос администрирования.
T>>Я имею в виду если кто-то выставит невалидный zip в приложении и сасабмитит в базу. G>1)в приложении все подряд не могут сабмитить в базу.
"кто-то" — какой-то сервис
G>2)Есть тесты, которые проверят правильность работы логики
А так она (валидация) будет в одном месте — в модели.
G>3)Саму валидацию на всех уровнях никто не отменял, но она содержится не классах сущностей, а вне их.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>>>По той причине, чтобы не дать перевести сущность/модель в невалидное состояние. Я же об этом уже писал. G>>>>Да пусть будет в невалидном состоянии, главное чтобы сущность не была сохранена в невалидном состоянии. Но это обеспечивается другими средствами. T>>>Какими? G>>Тойже валидацией, бизнес-правилами и прочим. Только она будет вне кода сущностей, в идеале задана декларативно и вызываться при сохранении.
T>Как она будет вызываться? Если какой-то сервис не станет ее вызывать, получим невалидные данные?
Валидация будет вызыватся при сохранении. Если у нас валидация задана декларативно, то можно через AOP заставить её проходить везде.
G>>>>service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
T>>>Зато данные не защищены от поломки из других сервисов G>>Для проверки такого есть тесты.
T>Если автор не захотел писать тест или автор — третье лицо, то смиримся с тем, что данные могут поломать?
А если автор не захотел писать проверки в классе?
Как это вообще касается архитектуры и дизайна?
Здравствуйте, gandjustas, Вы писали:
T>>Размер тут большого значения не имеет. Смогли скомпрометировать в одном месте, сможем и везде. G>А кто-то говорил про универсальность MaintainabilyIndex? Смотреть MaintainabilyIndex для частей проекта (классов, методов) полезно только для определения что влияет на индекс. Само значение индекса для одного класса\метода смысла практически не имеет.
"значение индекса для одного класса\метода" вносит свою ЛЕПТУ в общее значение индекса для всего проекта. Малую, но вносит.
Если классов много, N штук например, то вклад уже будет N * ЛЕПТА. Если мы для каждого класса подхачим ЛЕПТУ до меньшего значения лепта, то в совокупности это даст снижение на N * (ЛЕПТА — лепта). Что уже может иметь смысл.
Здравствуйте, gandjustas, Вы писали:
T>>Как она будет вызываться? Если какой-то сервис не станет ее вызывать, получим невалидные данные? G>Валидация будет вызыватся при сохранении. Если у нас валидация задана декларативно, то можно через AOP заставить её проходить везде.
То есть в промежутке между модификацией и сабмитом сущность вполне может быть в невалидном состоянии, значит любые методы, оперирующие этой сущностью должны уметь работать с невалидной сущностью тоже.
G>>>>>service.CloseLocation(licationId), остальное происходит внутри метода. А тот кто вызывает этот метод не имеет возможности сохранить в базе этот location.
T>>Если автор не захотел писать тест или автор — третье лицо, то смиримся с тем, что данные могут поломать? G>А если автор не захотел писать проверки в классе?
А это уже проблема модели. Важно то, что имеющиеся проверки никогда не будут (не могут) быть проигнорированы.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
G>>>>Вместо кастомера можно ченить еще придумать, где параметр валидации не находися в самой сущности. T>>>Нпример? G>>Просто представьте что такой кастомер. T>Какой такой? Если есть страна, то она где-то хранится. Следовательно её всегда можно узнать.
Замечательно, для загрузки кастомера из хранилища потребуется загрузка связанных сущностей.
G>>>>С этим вообще никак нельзя бороться, если кто угодно может получить доступ к базе, то смысла нет городить валидацию в приложении. Но это вопрос администрирования.
T>>>Я имею в виду если кто-то выставит невалидный zip в приложении и сасабмитит в базу. G>>1)в приложении все подряд не могут сабмитить в базу. T>"кто-то" — какой-то сервис
Тесты это отловят. Когда БЛ разбита на независимые сервисы тестировать становится лего и непринужденно.
G>>2)Есть тесты, которые проверят правильность работы логики
T>А так она (валидация) будет в одном месте — в модели.
Только это потребует гораздо больше "приседаний" чтобы валидация действительно везде работала, пример с zip code уже привели.
G>>3)Саму валидацию на всех уровнях никто не отменял, но она содержится не классах сущностей, а вне их. T>Где? Когда вызывается?
Как минимум при сохранении, например по событию SavingChanges.
Здравствуйте, Tissot, Вы писали:
T>Здравствуйте, gandjustas, Вы писали:
T>>>Размер тут большого значения не имеет. Смогли скомпрометировать в одном месте, сможем и везде. G>>А кто-то говорил про универсальность MaintainabilyIndex? Смотреть MaintainabilyIndex для частей проекта (классов, методов) полезно только для определения что влияет на индекс. Само значение индекса для одного класса\метода смысла практически не имеет.
T>"значение индекса для одного класса\метода" вносит свою ЛЕПТУ в общее значение индекса для всего проекта. Малую, но вносит. T>Если классов много, N штук например, то вклад уже будет N * ЛЕПТА. Если мы для каждого класса подхачим ЛЕПТУ до меньшего значения лепта, то в совокупности это даст снижение на N * (ЛЕПТА — лепта). Что уже может иметь смысл.
Это верно если все лепты независимы друг от друга. Но такого в жизни не бывает.
Здравствуйте, gandjustas, Вы писали:
G>>>Просто представьте что такой кастомер. T>>Какой такой? Если есть страна, то она где-то хранится. Следовательно её всегда можно узнать. G>Замечательно, для загрузки кастомера из хранилища потребуется загрузка связанных сущностей.
Зачем? Требуемая сущность будет загружена по требованию, при валидации.
T>>"кто-то" — какой-то сервис G>Тесты это отловят.
Лучший тест — это тест которого нет. Дзэнская мудрость.
G>Когда БЛ разбита на независимые сервисы тестировать становится лего и непринужденно.
А когда у тебя domain model необходимость тестирования валидности отпадает.
G>>>2)Есть тесты, которые проверят правильность работы логики
T>>А так она (валидация) будет в одном месте — в модели. G>Только это потребует гораздо больше "приседаний" чтобы валидация действительно везде работала, пример с zip code уже привели.
В примере с zip-ом лишь сказали, что такая проблема была. Как её решили сказано не было.
G>>>3)Саму валидацию на всех уровнях никто не отменял, но она содержится не классах сущностей, а вне их. T>>Где? Когда вызывается? G>Как минимум при сохранении, например по событию SavingChanges.
Тем самым только расширяется интервал времени когда модель будет в невалидном состоянии. Зачем оно? Не лучше ли не допускать невалидности модели?
