WCF Service и большие таблицы данных - любые альтернативы ddd/бизнес-объектам?

Question

Обычно я пытаюсь сфокусировать парадигмы, такие как DDD, имеют чистую архитектуру приложения, соленную с ORM, IoC и так далее. Теперь мне нужно настроить службу WCF, которая предоставляет полные таблицы данных (с ALOT столбцов), но редко имеет любую бизнес-логику/алгоритмы. Данные поступают из приложений CRM, которые просто необходимо передать через общую конечную точку (услугу WCF).

Применение проектов DDD или других объектов, связанных с объектами и бизнес-объектами, заканчивается написанием большого количества кода boillerplate, конфигураций ORM xml и кода инфраструктуры, которые кажутся слишком негативными для этих несколько примитивных требований.

Лучшим было бы иметь подход DataTable/DataSet, но, похоже, использование их с WCF является анти-шаблоном и считается плохим дизайном.

Итак, каковы альтернативы? Может быть, некоторые сериализации XML на основе анализа? Существуют ли общие шаблоны?

Редактировать: Данные из CRM записываются в базу данных SQL-сервера, которую я должен прочитать перед передачей данных. Схема изменяется довольно часто (добавляются новые столбцы), но мне не нужно заботиться о структуре, поскольку мне просто нужно передать данные в другое место. Вот почему мне понравилась идея заполнения DataSet/DataTables

Спасибо заранее.

Answer 1

Вы правы, говоря, что настройка всего этого только для службы WCF слишком высока.

DDD полезен, когда вы хотите создать бизнес-приложение, когда вам нужно смоделировать домен, с которым имеете дело. В вашем случае бизнес-приложение, похоже, является CRM, а не службой WCF.

Я предполагаю, что вы извлекаете данные из своего CRM-приложения через API.

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

Возможно, вам удастся перенести огромные графы объектов, но это лучше, чем пытаться перенести DataTables. То, что я хотел бы сделать, также заключается в том, чтобы инкапсулировать граф объекта ответа в объект methodName + Response (и, если необходимо, объект запроса в объект Name + объект запроса) для цели удобочитаемости.

Как только ваш контракт DTO и контракт на обслуживание были разработаны, все, что вам нужно сделать, это просто позвонить вашему CRM API, получить данные, а затем сопоставить их с DTO.

Убедитесь, что правильно отдельные вещи в вашей .sln, вот как я делал при работе с WCF услуг:

.WCF: веб-проект, который будет развернут, он содержит только файл .svc и файл .config.

. Интерфейс: Где я размещаю все контракты DTO и услуги.

.Implementation: Реализация сервиса (где вы будете называть ваш CRM API)

.Mapping: В DTO <> CRM отображение данных классов

Таким образом, все правильно разделены ,

Надеюсь, что это поможет!