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

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

Вот небольшая предыстория:

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

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

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

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


architecture c# asp.net vb.net business-logic
person Jason    schedule 28.10.2010    source источник
comment
Ваша предложенная структура хороша, за исключением того, что в идеале бизнес-логика и доступ к данным должны быть разделены, но это, несомненно, будет затруднительно, если большая часть этого содержится в существующих хранимых процессах.   -  person Mitch Wheat    schedule 28.10.2010

Ответы (4)


arrow_upward
1
arrow_downward

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

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

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

person Adam Ralph    schedule 28.10.2010

arrow_upward
2
arrow_downward

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

Смотрите это:

person Samu Lang    schedule 28.10.2010

arrow_upward
2
arrow_downward

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

ну лучше DAL отделить от SP

person abbas    schedule 02.02.2012

arrow_upward
1
arrow_downward

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

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

person Dismissile    schedule 28.10.2010