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