Фон
У нас есть собственная архитектура бизнес-объектов, гораздо более легкая (... и частично основанная на, но фактически не используемая...) версия структуры бизнес-объектов "CSLA" с аналогичным использованием, проверкой, включая DAL и т. д. Все генерируется код (сохраненные процедуры и бизнес-объекты создаются с помощью CodeSmith)
Бизнес-объекты довольно богаты функциями получения объектов, списков с параметрами сортировки фильтров для возврата объектов и общих списков.
Эта архитектура может не соответствовать одной конкретной или популярной архитектуре и пуризму, но она хорошо работает для нас и позволяет сократить объем ручного кодирования.
Одна вещь, которую мы часто находим, особенно при интеграции с другими системами (сторонними, Flash или Silverlight и т. д.), — это потребность в контекстуализированных «базовых объектах» или контейнерах данных, которые можно легко сериализовать и предоставлять через веб-сервисы и т. д. для конкретной цели.
Глядя на SO и в Интернет, часто встречается термин DTO. Мы создали эти базовые объекты в пространстве имен Dto. Эти объекты являются базовыми объектами, которые представляют базовые или определенные версии бизнес-объектов, но не имеют никаких функций, кроме конструкторов, которые принимают либо DataRow, либо бизнес-объект для заполнения объекта «Dto».
Вопросы:
1) Правильно ли называть это объектом "DTO"?
2) Вместо того, чтобы иметь конструкторы для предоставления данных и установки свойств объекта, этот код заполнения должен находиться в другом классе, своего рода "вспомогательном классе"
Любые комментарии по терминологии и соглашениям об именах для того, что я пытаюсь сделать?
Спасибо
