Переходя от ASP, бизнес-логика оказалась в ловушке хранимых процедур

Question

Как бы вы структурировали большой проект с большей частью бизнес-логики, уже находящейся внутри хранимых процедур?

Вот немного фона:

Мы переходим от классического ASP к ASP.NET (VB), и почти вся бизнес-логика находится внутри хранимых процедур. Извлечь логику практически невозможно, поскольку мой начальник не хочет (слишком дорого, слишком долго, никакой «реальной» добавленной стоимости).

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

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

Мне бы хотелось узнать ваше мнение о том, как бы вы структурировали новое приложение.

Answer 1

ну, ваша идея совершенно правильна .. Бизнес-логика не должна быть в процедуре Store. Я не амер, у меня большой опыт в разработке, и сейчас я работаю над проектом, в котором вся бизнес-логика в SP 'даже больше 1000 строкесть и динамические sql-запросы, и поверьте мне, я бросаю вызов любому гению, что вы не можете отлаживать SP. Единственное изменение в sp - это боль, и для понимания эффекта и изменений требуется много времени.

хорошо лучше DAL отделяют от SP

Answer 2

Я бы создал слой доступа к данным на основе Linq2SQL или Entity Framework, где вы могли бы ссылаться / сопоставлять свои существующие хранимые процедуры (также определяемые пользователем функции), а также таблицы.

См. Эти:

• Как: определить модель с помощью хранимой процедуры
• Хранимые процедуры (LINQ to SQL)

Answer 3

Будьте осторожны, чтобы не быть слишком увлеченным «извлечением логики» из хранимых процедур. Хранимые процедуры играют важную роль во многих приложениях. При правильном использовании они часто являются лучшим местом для инкапсуляции определенной логики. Хороший ответ относительно использования хранимых процедур - Использование StoredProcs в приложении

На стороне .NET ваш дизайн звучит разумно. Ваш DAL может обернуть слой хранимых процедур и абстрагировать постоянство ваших бизнес-объектов. Если вам все еще требуется отдельный уровень «бизнес-логики», он должен быть отделен от DAL.

В качестве внешнего интерфейса вы можете рассмотреть ASP.NET MVC, а не веб-формы ASP.NET. MVC - это шаблон, который более естественно вписывается в приложение на веб-странице и часто является более легкой целью миграции для классических сайтов ASP.

Answer 4

Это хорошая идея, чтобы отделить бизнес-логику от кода доступа к данным ... особенно, если это в хранимых процедурах. Проблема, однако, заключается в том, что ваш начальник, вероятно, не видит вас с глазу на глаз. Он видит просто перемещение кода asp в asp.net без изменения серверной части. Реорганизация системы будет дорогостоящей и отнимает много времени ... и существует большой потенциал для появления ошибок и т. Д.

Первый шаг - попытаться убедить вашего босса, что делать что-то подобное имеет смысл.