Мы реализуем веб-приложение SOA с использованием EF, WCF и jQuery.
Вот краткая информация о нашей архитектуре:
------------- ---
| UI | | |
------------- | |
| Services | | D |
------------- | T |
| Businsess | | O |
------------- | |
| Dal | | |
------------- ---
Мы знаем, что для этого нам нужны классы DTOпередавать данные между уровнями, особенно между Сервисами и пользовательским интерфейсом, но у нас есть некоторые концептуальные проблемы относительно способа использования DTO (для отправки в пользовательский интерфейс или получения из пользовательского интерфейса).
Для проекта, управляемого данными, мы можем использоватьPOCO для автоматического создания объектов DTO.Но в больших приложениях это не так просто.
Мы знаем два решения для решения нашей проблемы:
Первое решение (с использованием POCO помимо новых DTO, созданных вручную)
Например, предположим, что мыиметь сущность со многими полями.И есть выпадающий список, который показывает записи сущностей.Нам нужен просто ключ сущности в качестве поля значения поля со списком и другое поле (например, Название) в качестве поля со списком.Поэтому мы создаем метод с именем «GetAllItemsTitle» для извлечения всех сущностей.Теперь нам нужно просто вернуть желаемую структуру (ключ и значение в этом примере).Поэтому мы должны создать новый класс для хранения в нем этой структуры (ключ и значение).
Это будет новый класс DTO:
[DataContract]
public class SampleManuallyDto
{
[DataMember]
public long Id { get; set; }
[DataMember]
public string Title { get; set; }
}
И сигнатура методакак это:
public List<SampleManuallyDto> GetAllItemsTitle()
Второе решение (с использованием обнуляемых или пустых DTO)
Мы можем обойти POCO и создать DTO вручную.Затем мы можем определить все свойства DTO как обнуляемые или что-то в этом роде, которое может быть распознано как пустое (я назвал его пустым).Это позволяет нам использовать DTO для нескольких целей.Конечно, мы должны следовать шаблону адаптера.Например, создайте два метода для тех Emptyable DTO с именами «FromEntity» и «ToEntity», которые преобразуют наши DTO, созданные вручную, в EntityObjects (структуры сущностей).
Теперь мы можем обойти создание новых классов DTO впример «первого решения» (GetAllItemsTitle).
Подпись метода будет выглядеть следующим образом:
public List<SampleDTO> GetAllItemsTitle()
Но в теле метода мы просто заполняем «Id» и «Title»свойства SampleDTO.Как я уже сказал, все свойства SampleDTO могут быть пустыми, поэтому мы просто заполняем те, которые хотим, а остальные оставляем пустыми.
Заключение
Как правило, первое решение (с использованиемPOCO, кроме новых DTO, созданных вручную), имеет тип Strongy-Typed.Просто можно узнать каждый тип возвращаемых данных метода, просто посмотрев на сигнатуру метода (дополнительных свойств нет).Но мы беспокоимся об управлении вручную созданными DTO.Они скоро вырастут.
Но второе решение - более динамичный способ, и единственный способ узнать, что будет возвращено из «GetAllItemsTitle», - это просмотреть тело метода или его документацию.Поэтому мы беспокоимся о «ошибках времени выполнения».Разработчики могут предположить, что свойство не должно быть пустым, пока оно пустое.
Более того, наглядный пример, с которым мы столкнулись при такой проблеме, - «передача» данных из пользовательского интерфейса в службы.Например, для Обновления и Вставки и других подобных действий.Даже в отношении «критериев поиска» у нас есть такой же выбор.
Извините за длинный вопрос.Пожалуйста, помогите нам с любезными советами.