Я ищу указатели и информацию здесь, я сделаю это CW, так как я подозреваю, что у него нет ни одного правильного ответа. Это для C #, поэтому я сделаю несколько ссылок на Linq ниже. Я также прошу прощения за длинный пост. Позвольте мне обобщить вопрос здесь, а затем следует полный вопрос.

Описание: В четырехслойном приложении UI / BLL / DAL / DB, как можно изменить интерфейс пользователя, отображать больше столбцов (скажем, в сетке), избежать утечки через уровень бизнес-логики и в уровень доступа к данным, чтобы получить данные для отображения (при условии, что они уже находятся в базе данных).

Давайте рассмотрим многоуровневое приложение с 3 (4) слоями:

Пользовательский интерфейсУровень бизнес-логики (BLL)Уровень доступа к данным (DAL)База данных (БД; 4-й слой)

В этом случае DAL отвечает за построение операторов SQL и их выполнение в базе данных, возвращая данные.

Является ли единственный способ «правильно» создать такой слой, чтобы просто всегда делать «select *»? Для меня это большое нет-нет, но позвольте мне объяснить, почему мне интересно.

Допустим, я хочу, чтобы в моем пользовательском интерфейсе отображались все сотрудники, имеющие активную запись о занятости. Под «активным» я подразумеваю, что записи о занятости с сегодняшнего дня содержат сегодня (или, возможно, даже дату, которую я могу установить в пользовательском интерфейсе).

В этом случае, скажем, я хочу отправить электронное письмо всем этим людям, поэтому у меня есть код в BLL, который гарантирует, что я еще не отправил электронное письмо тем же людям и т. Д.

Для BLL нужны минимальные объемы данных. Возможно, он вызывает слой доступа к данным, чтобы получить этот список активных сотрудников, а затем вызов, чтобы получить список отправленных им электронных писем. Затем он присоединяется к ним и создает новый список. Возможно, это можно сделать с помощью уровня доступа к данным, это не важно.

Важно то, что для бизнес-уровня действительно не так много данных, которые ему нужны. Возможно, ему просто нужен уникальный идентификатор для каждого сотрудника, для обоих списков, чтобы сопоставить его, а затем сказать: «Это уникальные идентификаторы тех, кто активен, на которые вы еще не отправили электронное письмо». Затем я создаю код DAL, который создает операторы SQL, которые получают только то, что нужно бизнес-уровню? То есть. просто "ВЫБЕРИТЕ идентификатор из сотрудников, ГДЕ ..."?

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

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

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

Одно из предложенных предложений заключается в использовании Linq-To-SQL и IQueryable, так что если DAL, который имеет дело с тем, что (как в том, какие типы данных) и почему (как в предложениях WHERE) вернул IQueryables, BLL может потенциально вернуть их в пользовательский интерфейс, который затем может создать Linq-запрос, который будет извлекать необходимые данные. Затем код пользовательского интерфейса может получить нужные столбцы. Это будет работать, поскольку с IQuerables пользовательский интерфейс фактически завершит выполнение запроса, и затем он может использовать «select new {X, Y, Z}», чтобы указать, что ему нужно, и даже при необходимости присоединиться к другим таблицам.

Это выглядит грязно для меня. Пользовательский интерфейс выполняет сам код SQL, даже если он был скрыт за внешним интерфейсом Linq.

Но для этого BLL или DAL не должно быть позволено закрывать соединения с базой данных, и в мире IoC DAL-сервис может быть утилизирован немного раньше, чем хотелось бы коду UI, так что Запрос Linq может просто закончиться исключением: «Не удается получить доступ к удаленному объекту».

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

Пожалуйста, скажи мне, насколько мы глупы, и докажи, что я не прав?

И обратите внимание, что это устаревшая система. Изменение схемы базы данных в течение многих лет не входит в сферу применения, поэтому решение использовать объекты ORM, которые по сути делали бы эквивалент «select *», на самом деле не вариант. У нас есть несколько больших таблиц, которые мы хотели бы избежать, просматривая весь список слоев.