Правильно ли это «расслоение» моего веб-сервиса? Можно ли улучшить?

Я пишу веб-службу для извлечения информации о счете из таблицы базы данных. Специфика заключается в следующем:
В качестве ввода и извлечения я намерен дать InvoiceAgentIdPayerId, PayerName, EffDate и InvoiceAgentId.
Теперь
1. В файле InvoiceInfoSearch.asmx.cs у меня есть WebMethod ... GetInvoiceInfo
2. У меня есть DTO объекты InvoiceInfoRequest и InvoiceInfoResponse
3. У меня есть класс менеджера BusinessLayer InvoiceSearchmanager
4. У меня есть DAL InvoiceInfoDALПравильно ли это «расслоение» моего веб-сервиса? Можно ли улучшить?

веб-метод в точке # 1 инстанцирует InvoiceSearchManager класса и вызывает метод GetInvoiceInfo в менеджере пропускания InvoiceInfoRequest. Затем метод менеджер конкретизирует InvoiceInfoDAL и вызывает метод GetInvoiceInfo в DAL, передавая InvoiceInfoRequest. В методе DAL InvoiceInfoResponse создается и заполняется восстановленным набором записей, а затем распространяется обратно в веб-метод.

Мои вопросы:
1. Может обаInvoiceInfoRequest и InvoiceInfoResponse классы DTO имеют те же члены? В моем случае PayerId, PayerName, EffDate и InvoiceAgentId.
2. Правильно ли это наложение? Может ли это быть лучше?

источник

2010-07-14 GilliVilla

Есть ли причина, по которой вы все еще используете веб-службы ASMX? Microsoft теперь считает их «унаследованными технологиями». –

Поверьте мне ... на моем предприятии больше наследия. Я тоже хочу ... и asmx - последний из моих участников :). Мы продолжаем двигаться в плане фреймворков ... но в целом стандарты кодирования по-прежнему многого требуют включения. – GilliVilla

С точки зрения наслаивания ваше описание выглядит хорошо. Вы можете иметь те же имена методов в слоях DAL и Business. Проблема заключается в плотной связи. Как вы описываете, ваш веб-слой создает бизнес-уровень, создающий слой DAL.

Если это так, как вы планируете тестировать бизнес-уровень отдельно?

Я предлагаю вам ввести уровень абстракции в DAL и бизнес-уровни (путем реализации ими интерфейсов). Тогда реализация бизнес-уровня может использовать интерфейс DAL в качестве аргумента конструктора (встраивание конструктора) вместо того, чтобы создать экземпляр DAL.

Этот уровень абстракции позволит вам заменить реальный DAL в модульном тесте макетным объектом и протестировать бизнес-уровень изолированно.

Вся сантехника (инстанцирование) будет выполняться на уровне сети.

источник

2010-07-14 05:21:42

Спасибо за ответ! Достаточно ли для объектов запроса DTO и ответа иметь те же самые члены? – GilliVilla

Чтобы продолжить, исследуйте инфраструктуру инъекции зависимостей, такую как Spring.NET или аналогичный. Это создает «контекст приложения» - реестр, в котором уровни могут быть созданы или извлечены через интерфейс. Уровни в реестре можно определить по конфигурации. –

Если члены запроса DTO и ответа совпадают, возможно, вы можете использовать один и тот же класс для запроса и ответа: действительно, я видел, как это происходит довольно много раз. Однако часто бывает так, что более поздние изменения нуждаются в разных членах для запроса и ответа, а распутывание тесной связи - королевская боль. Поэтому лучше всего отделять их от начала ... –

Это все дело вкуса, однако мой подход был бы проще:

Controller (eg your *.asmx.cs) -> 
    Business Services -> 
    DAL

до вас. Тем не менее, моя архитектура подтверждается тем, что работает (например, не протирает зерно) весной и спящим в мире java. Я предполагаю, что C# следует подобным архитектурам.

источник

2010-07-14 05:42:32 Chris

Наложение, которое вы описываете, похоже на то, что используется OP. –

Правильно ли это «расслоение» моего веб-сервиса? Можно ли улучшить?

ответ

Смежные вопросы