Как передавать данные между BLL и пользовательским интерфейсом в трехуровневом (одноуровневом) приложении - PullRequest
Новая
       48

Как передавать данные между BLL и пользовательским интерфейсом в трехуровневом (одноуровневом) приложении

3 голосов
/ 04 декабря 2009

Я довольно начинающий программист, который пытается изучить основы n-уровневой архитектуры (DAL, BLL, UI). Приложение, которое я программирую, представляет собой одноуровневое трехслойное приложение, написанное на VB.NET (.Net 3.5). Слои следующим образом:

DAL

BLL

UI

COMMON - содержит DTO прямо сейчас.

У меня проблемы с определением того, что нужно передать между моим BLL и пользовательским интерфейсом. Мой инстинкт подсказывает мне, что я должен передавать только данные в пользовательский интерфейс, а не полный бизнес-объект из BLL. Рассмотрим два сценария:

1) Передайте BO напрямую из BLL в UI. Это предоставляет методы BO и позволяет UI иметь прямой доступ к BO, что кажется плохим.

2) Передавать только соответствующие данные из BO в пользовательский интерфейс. Например, у клиента есть имя и адрес. Эти данные действительно то, что мы хотим показать / отредактировать в пользовательском интерфейсе, поэтому мы будем возвращать эти данные только в пользовательский интерфейс вместо полного BO. Затем пользовательский интерфейс будет вызывать BLL для обновления определенного BO.

Я склонен использовать # 2, но я не знаю, как лучше всего это реализовать. Как я сейчас запрограммировал, если я только верну данные из BLL, все ссылки на мои BO будут потеряны, и GC потребует их. Исходя из этого, у меня есть несколько вопросов:

1) Должен ли я поддерживать бизнес-объекты между вызовами в BLL? Альтернативой является их повторное создание каждый раз, когда я передаю данные через BLL, что кажется неправильным.

2) Каков наилучший способ поддержать БО в одноуровневой архитектуре (как сохранить ссылку, если мы не передаем ее в пользовательский интерфейс?)

3) Как это делают n-уровневые приложения? Поддерживают ли они BO в BLL и ждут обновления от пользовательского интерфейса? Разве для этого не требуется много «бухгалтерского учета» в BLL, чтобы убедиться, что BO выпущены, когда они больше не нужны?

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

Ответы [ 2 ]

0 голосов
/ 04 декабря 2009

См. Зоомагазин в качестве примера трехслойной архитектуры. Я буду реализовывать как BLL, так и DAL как сервисный объект, который сам по себе не содержит никаких состояний. Поскольку они не имеют состояния, я могу использовать шаблон singleton и позволить factory сохранить его для удобства.

Вот несколько примеров методов CRUD, которые вы можете использовать: 

FooInfo DALFactory.FooService.Retrieve(int id);
FooInfo BLLFactory.FooService.Retrieve(int id);

IList<FooInfo> DALFactory.FooService.RetrieveAll;
IList<FooInfo> BLLFactory.FooService.RetrieveAll;

FooInfo DALFactory.FooService.Create(FooInfo entity);
FooInfo BLLFactory.FooService.Create(FooInfo entity);

FooInfo DALFactory.FooService.Edit(FooInfo entity);
FooInfo BLLFactory.FooService.Edit(FooInfo entity);

void DALFactory.FooService.Delete(FooInfo entity);
void BLLFactory.FooService.Delete(FooInfo entity);

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

Цель метода Retrieve и RetrieveAll - извлечь данные из базы данных и вставить их в объект сущности. Create метод добавляет новую строку в базу данных на основе данного объекта. В этой архитектуре нет «бизнес-объекта», кроме уровня BLLFactory.FooService уровня бизнес-логики и объекта FooInfo.

С точки зрения срока службы этих объектов BLLFactory.FooService без сохранения состояния создается один раз и будет использоваться повторно, пока приложение живо. FooInfo можно создать один раз для каждого объекта, а затем сохранить в сеансе ASP.NET или что-то в этом роде.

0 голосов
/ 04 декабря 2009

Вот как я всегда это делал:

Пользовательский интерфейс - ASP.Net или Windows выполняет вызов веб-службы
СЕРВИС - это сервисный уровень, который пользовательский интерфейс вызывает
COMMON - DTO - Объект передачи данных ключ находится на имя
BLL - содержит бизнес-объекты и код для сопоставления DTO с бизнес-объектами, и только DTO передаются на сервисный уровень DAL - доступ к данным

...