Почему бы вам не использовать службы данных WCF для запроса данных?

ОК, поэтому мы используем структуру сущностей и хотим предоставить данные от этих объектов потребителям. Эти данные довольно распространены и, хотя изначально они используются только приложениями WPF, в будущем могут использоваться другими технологиями, такими как Silverlight, ASP.NET, Office и т.д.

Как правило, вы должны создавать службы WCF, которые выставляют ряд явных методов для возврата данных в соответствии с потребностями потребителей. Например, GetCustomersById (int Id), GetAllCustomers() и т.д. Это приведет к накладным расходам на переписывание службы WCF и устранение проблем с версиями, если вам необходимо добавить другие методы в будущем. Вы также можете использовать DTO для возврата данных.

Итак, мы рассматриваем возможность простого раскрытия сущностей через службы данных WCF. Кажется, это имеет смысл. Это экономит усилия разработчиков, устраняя необходимость создания явных сервисов, реализующих различные интерфейсы. Это также может защитить вас от необходимости переписывать эти интерфейсы, если происходят изменения в ваших объектах.

Все кажется легким, и я уверен, что чего-то не хватает. Каковы недостатки этого подхода? Кроме того, если мы возвращаем объекты, а не DTO, что еще мы теряем?

Тогда есть очевидное следующее по вопросу, относящемуся к операциям обновления и удаления, которые вы также можете использовать. Стоит ли рассматривать службы данных WCF для этих операций?

Спасибо за понимание!

Ответ 1

Лично я предпочитаю ваш первоначальный подход, но это связано с моим желанием иметь сильный контроль над запросами и процессами, которые используются моими приложениями. я считаю, что, работая с очень крупными проектами, мне полезно иметь полный контроль над запрошенными запросами и т.д.

Ответ 2

Я думаю, что у вас есть действительный пример для Data Services. Они предназначены для предоставления данных в стандартном формате для конечных пользователей.

С учетом сказанного, аргументы против....

Недостатком является то, что вы в основном предоставляете им свободное владение, чтобы запрашивать данные, однако они хотят. В результате они могут делать глупые вещи и вызывать шею бутылки для других пользователей. Подумайте, как легко написать плохой запрос LINQ, который объединяет операции с памятью и БД.

Дополнительные аргументы против использования служб данных и использования традиционных сервисов - это когда у вас много бизнес-логики или вы хотите передавать типы данных, которые находятся за пределами вашей модели сущности (вы можете сделать это в 4.0, но это боль).

Наконец, мне всегда неудобно, когда речь заходит о вставке/удалении с помощью служб данных, потому что вы требуете, чтобы ваш конечный пользователь имел много знаний о том, как хранятся ваши данные. Вы должны доверять им, и я узнал, что доверие обычно возвращается, чтобы причинить вам вред.

Итак, в целом, Data Services великолепны, когда вам не нужно заставлять множество "правил" для ваших конечных пользователей (бизнес-логика или управление).

Ответ 3

Лично я считаю, что ваш первоначальный подход глуп. Это просто.

Службы данных позволяют пользователю фильтровать и запрашивать связанные данные по мере необходимости.
У служб данных уже есть полная интеграция инструментов - язык программирования (прохождение LINQ), службы Reporting Services, Excel могут работать против них.

В конце дня вы обнаружите способ использования более удобного API с меньшими затратами на обслуживание и поддержку инструментов.

Ответ 4

Службы данных, безусловно, являются экономией времени, но сама услуга не должна подвергаться напрямую, а через другие службы.

Мой подход состоял бы в том, чтобы иметь уровни служб: например, ваша служба фактически ведет себя как уровень данных, и так же, как вы не открываете базу данных клиентам, вы не предоставляете службу данных напрямую, а через услуги, которые добавляют дополнительную логику и ценность для данных (данные обработки, контроллеры, бизнес-логику, разрешения и т.д.). Это будет типичный подход, ориентированный на SOA...

Таким образом, если вы видите проблему при изменении модели базы данных, вы меняете только те сервисы, которые ее раскрывают, а не все. Как правило, если вы используете некоторую служебную шину Enterprise, у вас есть DTO, и вы сопоставляете свой объект с тем, с кем клиенты могут работать, тем самым избегая проблем с изменениями объектов. Конечно, вы могли бы сделать это вручную, но стоит сначала выяснить, стоит ли это...