#.net #wcf #entity-framework-4 #poco
#.net #wcf #entity-framework-4 #poco
Вопрос:
Есть ли какие-либо недостатки при использовании одних и тех же POCO (в EF4 и WCF) на разных уровнях (DAL, BLL и Presentation) и обходиться без DTO? Клиенты и службы — это все.СЕТЬ и все приложение не очень большие.
Я спрашиваю об этом, потому что перемещение одних и тех же данных между уровнями в разных форматах и выполнение преобразований и сопоставлений кажется хлопотным и добавляет сложности. Разработка и обслуживание требуют больше времени и подвержены ошибкам. Я не уверен, стоит ли добавлять DTO, даже если DTO генерируются во время выполнения или используются генераторы DTO.
Я хотел бы услышать некоторые мнения, поскольку я начинаю разрабатывать и кодировать новое веб-приложение.
Комментарии:
1. «Я хотел бы узнать несколько мнений …» Я не собираюсь отмечать это, но должен ли этот вопрос касаться «программистов», а не переполнения стека?
2. Я до сих пор понятия не имею, что относится к stackoverflow, а что к программистам 🙂
3. И в этом проблема. Так что он просто включается, потому что получает больше трафика.
4. Если тема слишком общая, она может перейти к программистам. Лично я бы хотел, чтобы programmers SE не существовал, потому что он разделил сообщество на две части. Можно использовать специальный тег.
5. @Tony — Я согласен. Я видел несколько дебатов по этому поводу, но, похоже, все еще достаточно сторонников программистов, чтобы продолжать в том же духе. IMHO различие слишком тонкое, и кажется, что многие вопросы находятся в серой области между ними и, возможно, даже соответствуют обоим описаниям того, что принадлежит каждому сайту. «Субъективность» вопроса зависит от того, кто спрашивает, является ли он субъективным, что также показывает, что само различие субъективно . ИМХО тот факт, что так много людей считают различие слишком расплывчатым или тонким и, в конечном счете, не понимают его, демонстрирует, что его не должно существовать.
Ответ №1:
Одной из основных причин использования DTO является необходимость передачи представлений объектов по проводам.
Если вы используете объекты своей модели домена в рамках одного процесса, то вы вполне можете использовать одни и те же объекты повсюду.
Если, с другой стороны, вы планируете сериализовать свои объекты и отправить их другим процессам, например, через веб-службу, то обычно лучше делать это с помощью DTO, которые формируют согласованные контракты данных между двумя процессами. Аннотации данных могут быть использованы для обогащения этого договорного соглашения. Оба процесса потенциально могут использовать одну и ту же сборку контракта данных для сериализации и десериализации обратно.
Каждый процесс в такой архитектуре, вероятно, будет иметь различную цель (отсюда и разделение) и, следовательно, будет иметь разные требования от объектов, например. один может быть графическим интерфейсом, связанным только с представлением, другой может быть уровнем бизнес-логики, связанным с изменением объектов, позволяя им взаимодействовать, придерживаясьдля бизнес-правил другим может быть уровень доступа к данным, связанный только с сохранением, а другим может быть денормализатор, связанный с преобразованием объектов для механизма отчетности и т. Д. Это означает, что единственной вероятной общностью в требованиях между уровнями является представление данных, т. Е. DTO или контракт данных, а не поведение объекта с расширенной моделью предметной области. В приведенных примерах единственным уровнем, которому нужен богатый объект с поведением, является уровень бизнес-логики.
DTO также может быть лучшим способом передачи представлений объектов между доменами приложений, если это то, что от вас требуется.
Ответ №2:
По проводам означает, что ваши данные видны по всему проводу.
После успешной аутентификации пользователя любой сетевой инструмент может выявить все переданные данные. Если вы передаете весь объект целиком и показываете только вставки объекта в пользовательском интерфейсе, то вы предполагаете, что пользователь не увидит ваши скрытые данные. Но с любым инструментом трассировки сети все видно.
Вы должны представить, что вы на самом деле отправляете полные данные, а пользовательский интерфейс — это просто презентация.
Итак, если пользователь может просматривать данные через трассировку сети, тогда беспокоиться не о чем.
Но помните, что кто-то с плохими намерениями может попытаться манипулировать данными, которые вы, возможно, проигнорировали, учитывая, что у пользователя никогда не будет доступа к нему. Например, вы можете создать поле username только для чтения, и ваш пользовательский интерфейс не позволит пользователю изменять, но кто-то может легко написать код клиента wcf для подключения к вашей службе.
Большинство проблем возникает из-за внешних ключей, если кто-то манипулирует внешними ключами, будет сложно проверить право собственности на объект.
Вы должны предполагать, что каждый запрос по проводам является и будет вредным, и безопасность должна быть проверена на все возможности.
Ответ №3:
Недостаток начинается, и это всего лишь пример, но представьте, что ваш дизайнер пользовательского интерфейса приходит с простым и невинным вопросом. Разве мы не можем сохранить позиции x и y, где объект отображается на экране, в самом объекте? Разве у меня не может быть свойства «Выбрано» для объекта, которое указывает, выбрано ли оно в данный момент или нет? И вы думаете: выбранное свойство, черт возьми, нет! Я не могу записать это в базу данных, это не имеет никакого смысла. И затем они хотят, чтобы ваш POCO реализовал INotifyPropertyChanged и получил некоторые пользовательские события и так далее.
Преимущество DTO и сопоставления заключается в разделении ваших слоев. Вы улучшаете свои возможности по настройке своих объектов в соответствии с требованиями каждого уровня.
В настоящее время есть несколько удобных инструментов сопоставления, которые должны упростить эту задачу. AutoMapper — один из них. Другое дело — генерация кода с помощью шаблонов T4.