По сути код работает со структирированными данными. Назовем бизнес-объекты.
Практически в каждом проекте эти данные используются для 4-5 вещей:
1. Для внутреннего потребления, т.е. вы некие классы передаете/принимаете в своих методах и что-то с ними делаете.
2. Для сохранения. Как правило ORM позволяет сохранять сами эти структуры данных. Но так просто не получается -- их нужно либо наделить атрибутами либо кодогенерацией (ну или XML-описанием).
3. Эти же структуры данных иногда приходится сохранять на диск в неком формате без ORM. К примеру для сохранения в xlsx-файл.
4. Эти же структуры вам нужно отдавать через REST/SOAP-API внешним пользователям.
5. Эти же структуры вам нужно получать из внешнего API, от которого уже вы зависите.
Главное неудобство вижу в том, что по стуи очень похожие структуры в каждом из этих 5 случаев нужно копировать одну в другую. Потому что они хотя и похожи, порой на 90%, но все же отличаются. К примеру в одном случае требуется обязательное наличие set-еров, иначе библиотека отказывается работать с данными (к примеру, стандартная XML-сериализация требует чтобы у списка был set-ер). Но наличие set-еров противоречит внутренней парадигме.
Видите ли вы проблему в том что по сути одни и те же данные по многу раз приходится копировать из одной структуры в другую лишь по той причине, что они применяются в разных слоях (но по стуи одинаковые сущности)?
Здравствуйте, Shmj, Вы писали:
S>Видите ли вы проблему в том что по сути одни и те же данные по многу раз приходится копировать из одной структуры в другую лишь по той причине, что они применяются в разных слоях (но по стуи одинаковые сущности)?
Я считаю нормальным, что одни и те же данные видоизменяют свое представление в зависимости от задачи.
А сталкивался обратной с проблемой. Варианты представления одних и тех же данных рассматривались как независимые друг от друга. И обработчики имели независимые. В результате, приходилось одни и те же правки вносить в разных участках кода.
Re[2]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Mihas, Вы писали:
M>Я считаю нормальным, что одни и те же данные видоизменяют свое представление в зависимости от задачи.
Что вы имеете в виду под представлением? То что для каждого случая вы создаете на 90% совпадающие классы?
M>А сталкивался обратной с проблемой. Варианты представления одних и тех же данных рассматривались как независимые друг от друга. И обработчики имели независимые. В результате, приходилось одни и те же правки вносить в разных участках кода.
Если создаете классы для каждого из 5 случаев -- то при изменении структуры данных правки придется вносить везде.
Re: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Shmj, Вы писали:
S> Но наличие set-еров противоречит внутренней парадигме.
Вот с этого и надо начинать. Если некая свежепровозглашённая шиза не вписывается в практичную логику, это не "парадигма", а сферический конь в вакууме.
S>Видите ли вы проблему в том что по сути одни и те же данные по многу раз приходится копировать
Разумеется! Поэтому я делаю проще — создаю комбинированные классы.
1. В них есть все поля, чётко ложащиеся на поля СУБД.
2. Поля не для СУБД помечаем как SqlIgnore — это те самые полезные "бизнес-проперти".
3. Сериализация в JSON у нас используется во всю ширь, поэтому так же как с СУБД, что не надо — помечаем JsonIgnore.
В результате, один и тот же класс СПОКОЙНО вращается в бизнес логике, прыгает в сторидж и обратно, сериализуется для внешних API и радует прогера безо всяких вырвиглазных MVVM/MVC и т.п.
Re[2]: Про бизнес-объекты: для сохранения, для API, для внут
Здравствуйте, Kolesiki, Вы писали:
K>Вот с этого и надо начинать. Если некая свежепровозглашённая шиза не вписывается в практичную логику, это не "парадигма", а сферический конь в вакууме.
С коллекциями ошибся, оказывается и без сетеров сериализация работает. Но как быть с другими свойствами? Если один объект для всего, то вообще нельзя создавать только get-свойства. Получается если передали объект в метод -- нет гарантий что он там не подвергнется изменениям.
M>>Я считаю нормальным, что одни и те же данные видоизменяют свое представление в зависимости от задачи. S>Что вы имеете в виду под представлением?
Под представлениями я понимаю перечисленное в стартовом посте:
1. Для внутреннего потребления
2. Для сохранения через ORM
3. для сохранения в xlsx-файл.
4. В структуре REST/SOAP-API
Один и тот же элемент данных (например, описание товара) нужно представлять в той или иной структуре.
M>>А сталкивался обратной с проблемой. Варианты представления одних и тех же данных рассматривались как независимые друг от друга. И обработчики имели независимые. В результате, приходилось одни и те же правки вносить в разных участках кода. S>Если создаете классы для каждого из 5 случаев -- то при изменении структуры данных правки придется вносить везде.
Что-то обязательно можно вынести в общую часть.
Re[4]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Mihas, Вы писали:
S>>Если создаете классы для каждого из 5 случаев -- то при изменении структуры данных правки придется вносить везде. M>Что-то обязательно можно вынести в общую часть.
То есть вы предлагаете использовать наследование?
Re[5]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Shmj, Вы писали:
S>Те же коллекции не должны иметь set-еров по этим рекомендациям. А для XML-сериализации/десериализации, к примеру, они обязательны.
Поправочка: если это коллекция (ICollection<T>, IDictionary<TKey,TValue>, ISet<T> или их наследники), то сеттер не нужен, все и так работает, если
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Re[6]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Kolesiki, Вы писали:
K>В результате, один и тот же класс СПОКОЙНО вращается в бизнес логике, прыгает в сторидж и обратно, сериализуется для внешних API и радует прогера безо всяких вырвиглазных MVVM/MVC и т.п.
Вот в идеале хотелось бы такое, чтобы 1 класс создавался на одну сущность. Ну или в крайнем случае наследование.
Но есть два минуса:
1. Если используете тот же EF CodeFirst, то нужно помечать атрибутами поля. А это значит что библиотека ваших контрактов будет иметь зависимость на конкретную ORM.
2. Все поля должны быть get и set, даже если по вашей внутренней логике объект не мутабельный. Фактически любой ваш объект может быть изменен в любом слое, вы не можете этого запретить.
Re[6]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, rameel, Вы писали:
R>Поправочка: если это коллекция (ICollection<T>, IDictionary<TKey,TValue>, ISet<T> или их наследники), то сеттер не нужен, все и так работает, если
✓ DO create get-only properties if the caller should not be able to change the value of the property.
Keep in mind that if the type of the property is a mutable reference type, the property value can be changed even if the property is get-only.
По вашей схеме вообще не будет никакой возможности сделать get-only свойства. Вообще никак. Все должны быть и get и set.
А что если ваш объект требует неизменности? Вы его передаете и должна быть гарантия что метод его не изменит. Что тогда?
Re[7]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Shmj, Вы писали:
S>Здравствуйте, Sharov, Вы писали:
S>>Для 1-3 -- наследование, подвязанное к ORM. 4-5 -- dto с трасфорамацией в бизнес объекты.
S>А конкретно. Вы создаете объекты в EF DB-First/Model-First а потом наследуетесь от них? Т.е. вся ваша архитектура гвоздями прибита к EF?
У меня сценарий проще, поэтому всюду использую сгенерированные orm объекты (у меня telerik openaccess). В случае передачи объектов между сервисами,
использую трансформацию в dto, которую для меня тот же orm уже сгенерировал. Трансформация выполняется копированием полей+какая-то специфичная бизнес логика.
Кодом людям нужно помогать!
Re: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, Shmj, Вы писали:
S>Видите ли вы проблему в том что по сути одни и те же данные по многу раз приходится копировать из одной структуры в другую лишь по той причине, что они применяются в разных слоях (но по стуи одинаковые сущности)?
Нет тут никакой проблемы.
Определяешь 5 разных классов, и все. Если попытаешься переиспользовать один — все закончится кашей (перемешиванием разных модулей и слоев)
Копируешь автомаппером например (самая распространенная либа для этого на .net) — обеспечивает гибкое эффективное копирование "похожих" объектов.
Re[5]: Про бизнес-объекты: для сохранения, для API, для внутреннего
Здравствуйте, bnk, Вы писали:
bnk>Нет тут никакой проблемы. bnk>Определяешь 5 разных классов, и все. Если попытаешься переиспользовать один — все закончится кашей (перемешиванием разных модулей и слоев) bnk>Копируешь автомаппером например (самая распространенная либа для этого на .net) — обеспечивает гибкое эффективное копирование "похожих" объектов.
Не ясно почему обязательно получится "каша".
А про копирование. Ведь есть такое понятие как конструктор и он вызвается при создании класса. Там указываются обязательные поля. А ваш automapper знает про конструкторы и обязательные поля?
Или вы предлагаете отказаться от концепции конструкторов, оставлять его всегда пустым и просто использовать метод VilidateInstance для проверки установлены ли обязательные поля?
Re[6]: Про бизнес-объекты: для сохранения, для API, для внут
Здравствуйте, rameel, Вы писали:
R>Я ответил на вот это вот: S>> А для XML-сериализации/десериализации, к примеру, они обязательны.
Да, для коллекций оказывается не обязательны.
Но по предложенной выше парадигме с использованием единого класса для всего -- вообще все свойства будут имет обязательно и get и set. А что если объект не подразумевает возможность изменений?
Здравствуйте, Shmj, Вы писали:
S>Но по вашей парадигме вообще все свойства будут имет обязательно и get и set. А что если объект не подразумевает возможность изменений?
Какой парадигме?! Я вообще-то один раз только написал, указать, что для стандартной XML (де)сериализации коллекции не обязательно наличии сеттера.
Вопрос я думаю адресуется не ко мне, я в дискуссии не учавствовал
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>
Re[7]: Про бизнес-объекты: для сохранения, для API, для внут
Здравствуйте, Shmj, Вы писали:
S>Но по предложенной выше парадигме с использованием единого класса для всего -- вообще все свойства будут имет обязательно и get и set. А что если объект не подразумевает возможность изменений?
Здесь я с тобой согласен, если что. Если объект не подразумевает изменений, то и класс проектируется соответствуюшим образом
... << RSDN@Home 1.0.0 alpha 5 rev. 0 on Windows 8 6.2.9200.0>>