Да, плагин — вариант. Но для этого нужен сервис, который будет вещать в лосслесс со своим плагином. Мне такие не встречались, но сам бы пользовался с удовольствием.
Я как-то тоже интересовался этим вопросом. Для того, чтобы стримить lossless по HTTP нужен кодек который будут поддерживать браузеры, но пока разработчикам браузеров это не интересно. Инфа примерно 1,5 года давности.
вынесите данные в сервис и обратитесь к нему через сервис-локатор
Я почитал немного про сервис-локаторы. Можно небольшой пример как передать атрибуту именно локатор, у которого он может получить сервис?
Я вижу проблему в том, что при каждом обращении к атрибуту объекта через рефлексию создается новый экземпляр атрибута, поэтому вариант с установкой локатора через сеттер свойства не подходит.
С другой стороны задать конкретный локатор в конструкторе мы не может т.к. там должна быть либо константа времени компиляции либо тип.
Я что-то упускаю или не правильно понял реализацию сервис-локатора?
когда выполняется валидатор, определенный атрибутом на классе
Для MVC при байндинге модели, так же как и DA.
почему в нем не следует задавать правила для отдельных свойств
Не совсем понял вопрос. Но столкнулся с ситацией когда определен DA атрибут [Required] и FV NotEmpty() при построении представления происходило исключение связанное с тем, что для свойства одно и тоже правило было задано несколько раз.
Понятнее? Нет, потому что мы перестаем видеть бизнес-правила.
В студии довольно просто перейти к определению класса атрибута и посмотреть бизнес-правила. Тут, наверное, кому как удобнее. Мне было сложно визуально выделять атрибуты валидиции, особенно условные с зависимостями на другие свойства. Они было громоздкие.
Если в модели для каждого свойства заданы несколько атрибутов для валидации (обязательность, длина, регулярное выражение, какой-то кастомный, например) — модель превращается у «ужасного монстра». А если добавить еще и локализацию — то сложно будет разглядеть свойства под навешанными атрибутами.
При FV добавляется всего один атрибут класса и вся логика находится в нем. Модель становится намного легче и понятнее.
В статье я только поверхностно коснулся того, что такое FV.
По поводу тестирования атрибутов — это отельный вопрос. Мне нужно было для валидации получать данные из БД. Замокать логику доступа к данным в атрибуте в юнит тестах довольно сложно, потому что это метаданные класса, нельзя использовать наследование или заменить атрибут во время выполнения. С FV это делается очень просто.
Чуток погуглив нашел вопрос на stackoverflow. Видимо, фейкать нужно как раз свойство DependencyInjector.Current.
Да, теперь понятнее, а то не складывалась картинка, не хватало пазла, спасибо =)
Я почитал немного про сервис-локаторы. Можно небольшой пример как передать атрибуту именно локатор, у которого он может получить сервис?
Я вижу проблему в том, что при каждом обращении к атрибуту объекта через рефлексию создается новый экземпляр атрибута, поэтому вариант с установкой локатора через сеттер свойства не подходит.
С другой стороны задать конкретный локатор в конструкторе мы не может т.к. там должна быть либо константа времени компиляции либо тип.
Я что-то упускаю или не правильно понял реализацию сервис-локатора?
Упустил этот момент, спасибо.
Не до конца понял какие именно ситуации. Можно ссылочку где это можно посмотреть?
Для MVC при байндинге модели, так же как и DA.
Не совсем понял вопрос. Но столкнулся с ситацией когда определен DA атрибут [Required] и FV NotEmpty() при построении представления происходило исключение связанное с тем, что для свойства одно и тоже правило было задано несколько раз.
В студии довольно просто перейти к определению класса атрибута и посмотреть бизнес-правила. Тут, наверное, кому как удобнее. Мне было сложно визуально выделять атрибуты валидиции, особенно условные с зависимостями на другие свойства. Они было громоздкие.
Для простых правил DA мне тоже отлично подходит.
При FV добавляется всего один атрибут класса и вся логика находится в нем. Модель становится намного легче и понятнее.
По поводу тестирования атрибутов — это отельный вопрос. Мне нужно было для валидации получать данные из БД. Замокать логику доступа к данным в атрибуте в юнит тестах довольно сложно, потому что это метаданные класса, нельзя использовать наследование или заменить атрибут во время выполнения. С FV это делается очень просто.