Должен ли я начать добавление / преобразование физического бизнес-уровня в существующий проект?

Question

Должен ли я начать добавление / преобразование физического бизнес-уровня в существующий проект?

1

Совсем недавно наше приложение расширилось для поддержки 4 разных пользовательских интерфейсов.

У нас есть бизнес-логика, которая интегрирована в наш уровень данных.

У нас нет физического бизнес-уровня, который отделяет наш интерфейс от нашего уровня данных. Часто в пользовательском интерфейсе база данных вызывается непосредственно. Очевидно, это вызывает проблемы.

Мой вопрос в том, должен ли я реализовать физический бизнес-уровень и со временем перенести существующую логику в слой данных на новый бизнес-уровень. Или я должен поддерживать бизнес-уровень в той же DLL, что и уровень данных?

Что вы думаете о добавлении бизнес-уровня в приложение без него?

drizzie 30 март 2015, в 17:03

Источник

0

Пожалуйста, уточните немного. Что вы подразумеваете под слоем данных. У вас есть модель данных и отдельный слой данных? Как интегрируется существующая логика в слой данных - есть ли у вас хранимые процедуры?
Plamen Petrov 22 апр. 2015, в 07:03
0

Извините, под слоем данных я имел в виду уровень доступа к данным. Мы используем Linq to Sql и используем всю нашу бизнес-логику в классах расширения.
drizzie 22 апр. 2015, в 11:55

Теги:

c#

n-tier

n-tier-architecture

business-logic

business-layer

1 ответ

Ещё вопросы

Пожалуйста, уточните немного. Что вы подразумеваете под слоем данных. У вас есть модель данных и отдельный слой данных? Как интегрируется существующая логика в слой данных - есть ли у вас хранимые процедуры?
Извините, под слоем данных я имел в виду уровень доступа к данным. Мы используем Linq to Sql и используем всю нашу бизнес-логику в классах расширения.

Plamen Petrov · Accepted Answer · 2015-04-23T06-01-00.000Z

Вы должны определенно ввести некоторое разделение проблем, делая вещи в разных слоях. Непосредственная ссылка на базу данных из пользовательского интерфейса не является звуковой архитектурой и приведет к жесткой связи и трудностям в обслуживании и расширении позже.

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

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

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

Удачи!