Не знаю достаточно, чтобы понять, является ли этот дизайн отличной идеей или невероятно глупой ...

Question

Использование C #, asp.net 3.5, SqlServer 2005,

Попытка включить некоторую инверсию управления вместе с 3-уровневой архитектурой в мое текущее назначение.

Не знаю достаточно, чтобы понять, хорошая ли это идея или невероятно глупая:

Я создал уровень пользовательского интерфейса, бизнес-уровень и уровень данных.

Пользовательский интерфейс собирает 4 значения, News - экземпляр класса Business Layer (назовем его c), инициализируя его 4 значениями.

Затем пользовательский интерфейс вызывает метод этого экземпляра класса Business Layer для сохранения данных.

Метод класса Business Layer создает строку tsql, такую ​​как

String.Format (@ ”вставить в table1 (col1, 'col2', 'col3', col4) значения ({0}, {1}, {2}, {3}); выбрать @@ identity”, c.one, c.date1, c.date2, c.four);

и передает строку в метод int класса на уровне данных.

Уровень данных использует строку в качестве CommandText для ExecuteScalar и возвращает идентификатор @@ в Бизнес-уровень.

Я бы использовал вариант той же концепции для извлечения данных через устройство чтения данных.

Объем данных не будет большим, и это не будет приложение большого объема.

В прошлом я делал так, чтобы передать 4 значения, собранные в пользовательском интерфейсе, через бизнес-уровень на уровень данных, настроить sqlparms, передать значения в хранимую процедуру и т. Д., Передать их обратно в бизнес уровень и т. д.

Answer 1

О, дорогой! Мне так много нужно сказать, что я даже не знаю, с чего начать.

Во-первых, я действительно не вижу, к чему здесь подходит IoC, поскольку вы new повышаете классы влево и вправо.

Затем вы заставляете свой слой BL создавать оператор SQL, чего не должно быть. Еще хуже то, что вы в основном объединяете строки, чтобы получить оператор SQL. Это ужасная, ужасная практика (см. SQL-инъекция ).

Теперь я не вижу никакой "бизнес-логики" внутри вашего BL. И вы бездельничаете с сырым ADO.NET, который в наше время огромен, нет (кроме случаев, когда вы оптимизируете производительность). Проверьте NHibernate или BLToolkit .

Вот что я рекомендую. Посмотрите, что такое Service Layer , и попробуйте выделить "сервисы" в вашей системе. Поскольку у вас пока нет никакой «бизнес-логики», я вижу IFooPersistenceService, являющийся единственным сервисом.

Далее читайте о MVP и MVC . Это поможет вам лучше построить свой пользовательский интерфейс.

И, наконец, вот как я вижу общий поток контроля.

Пользователь вводит несколько значений в той или иной форме и нажимает кнопку «Сохранить». Ваш IView вызывает событие Saved, которое обрабатывается IPresenter. Затем он извлекает эти значения из свойств IView, создает бизнес-объект (или, в этом отношении, граф объектов) для хранения этих значений, вызывает IFooPersistenceService (с Foo, являющимся именем объекта), чтобы сохранить его в БД. IFooPersistenceService вызывает любую выбранную вами ORM и возвращает значение @@SCOPE_IDENTITY в IPresenter.

Как только вы начнете иметь какую-либо логику, добавьте дополнительный слой между IPresenter и IFooPersistenceService, чтобы сохранить указанную логику.

См. и (рекурсивно).

Answer 2

Нет, я думаю, что ваш новый путь намного хуже, чем ваш предыдущий. Использование String.Format оставляет вас открытыми для атак с использованием SQL-инъекций, если вы не будете осторожны.

Если вы на самом деле не выполняете логику в своем слое «Business Logic», я бы просто удалил ее, и ваш «Уровень данных» вызвал сохраненный процесс.

Answer 3

Если это имеет смысл для вас (и вашей команды) и работает как задумано, это прекрасный шаблон дизайна, независимо от того, что это такое.

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

Answer 4

Мой подход к хорошему дизайну в веб-приложении заключается в том, что на бизнес-уровне вы моделируете свое приложение объектно-ориентированным способом и определяете свои бизнес-правила. Бизнес-уровень - это ядро ​​вашего приложения. В типичном веб-приложении вы много раз будете просто передавать данные через бизнес-уровень, но оно все равно создает хорошее разделение между данными и пользовательским интерфейсом, и в любом случае это код, который очень легко писать и поддерживать, поэтому не стоит сильно беспокоиться, если это кажется ненужным кодом.

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

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

Когда дело доходит до пользовательского интерфейса, в идеале вы должны создать свой интерфейс бизнес-уровня таким образом, чтобы можно было использовать различные пользовательские интерфейсы (Webforms, mvc, silverlight). Если вы создадите хорошее приложение, оно будет жить много лет, и пользовательский интерфейс, вероятно, будет меняться много раз, и много раз будет создано несколько пользовательских интерфейсов. Ваш бизнес-уровень не должен заботиться о том, что вы используете в качестве уровня пользовательского интерфейса, таким образом вы получаете хорошее разделение между уровнями.