Мне кажется, что ответственность между уровнями немного запутана. Слой данных звучит довольно стандартно. (Так называемый) бизнес-уровень - это место, где все запутано.
Некоторые мысли о бизнес-уровне:
Кажется, есть много представлений данных. Вы упоминаете DataTables, DataSets, объекты передачи данных. Стандартный подход ко всему приложению был бы лучше.
Методы бизнес-уровня с именами, такими как ReturnNthRecordSetFromStoredProcFoo и ReturnDataSet, не имеют смысла и не обеспечивают соответствующий уровень абстракции для бизнес-сервисов. (Может быть, это были просто плохо выбранные примеры не из приложения?)
Как правило, бизнес-уровень обеспечивает больше, чем проходит набор данных. Вместо того чтобы иметь дело с отображениями, нулями и т. Д., Бизнес-уровень должен сосредоточиться на проверке, бизнес-правилах, безопасности и, возможно, даже аудите (хотя некоторые предпочитают делать это в базе данных).
Несмотря на то, что бизнес-уровень вызывает только одну хранимую процедуру, у меня нет проблем с управлением транзакциями на бизнес-уровне. Бизнес-уровень должен контролировать транзакцию, чтобы все объекты данных могли участвовать в одной транзакции (она может даже находиться в разных базах данных). Несмотря на то, что сейчас есть только один вызов, если вам когда-либо понадобится добавить больше вызовов в будущем, это будет легко и не приведет к модификации управления транзакциями в вашем приложении.
Я думаю, что с зависимостями все в порядке - нет ссылки на Web.UI или SQLClient из бизнес-уровня.
Правила авторизации также в порядке. Я бы расширил, чтобы включить безопасность, а не только авторизацию. Кроме того, я нигде не вижу бизнес-логики - просто интересно, есть ли бизнес-логика в хранимых процедурах? Если бы я собирался угадать, я бы сказал да, учитывая, что каждый бизнес-метод вызывает только одну хранимую процедуру. Если это так, то это большое нет, нет для меня.
Я бы не совмещал бизнес и уровень данных. Я предпочитаю разделять уровень бизнес-логики и уровень доступа к данным. Если бы у меня был выбор между их объединением и попыткой немного разделить обязанности, я бы склонялся к последнему.
Однако, учитывая, что это существующее приложение с проблемами, я бы выбрал более прагматичную точку зрения. Все идет со стоимостью, и важно определить, какие изменения вносятся, каковы усилия и риск этих изменений, какова реальная польза от изменений и как изменения повлияют на цикл тестирования.
Некоторые другие вопросы для размышления: какие основные проблемы вы хотите решить? Являются ли они функциональными (например, ошибки, отсутствие стабильности)? Или производительность связана? Или это архитектурно? Или, возможно, связано с ремонтопригодностью - вам нужно добавить новую функциональность, но вам сложно? У вас есть временные рамки или бюджет? Если вы сможете ответить на некоторые из этих вопросов, это может помочь вам.