Как использовать BLL, DAL и модель?

Question

В моей компании я должен использовать слой Bll, Dal и модель для создания приложений с базой данных.

В школе я узнал, что каждая таблица базы данных должна быть объектом в моей модели. поэтому я создаю всю модель своей базы данных. Также я узнал, что для каждой таблицы (или объекта модели) в DAL должен быть создан DAO. Так что я делаю это для.

Теперь я застрял в классах BLL. Я могу написать BLLclass для каждого DAO / ModelObject или я могу написать BLLclass, который объединяет некоторые (логические) DAO ... Или я могу написать только один класс Bllclass, который будет управлять всем. (это последний, я уверен, что это не лучший способ ..)

Как лучше всего справляться с этой «проблемой» Bll?

И второй вопрос. Если bll нуждается в содержании таблицы из другой таблицы, за которую он не отвечает, каков наилучший способ получить содержимое? Иди спроси у ответственного BLL или иди прямо в DAO?

Я борюсь с этими вопросами последние 2 месяца, и я не знаю, как лучше всего с ними справиться.

Answer 1

Вы должны начать с того, что вам нужно, чтобы приложение заработало.

Например: «Мне нужен веб-интерфейс для входа пользователя»

1. Итак, мне нужен контроллер, использующий модель для проверки псевдонима и передачи
2. Тогда мне нужен объект bll, чтобы сделать логику для проверки псевдонима и передать
3. Затем мне нужен объект dal для доступа к базе данных для получения информации о пользователе.

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

примечание: если dal является orm-отображением или нет, анекдотично. Также, если модель использует bsl или bsl, используйте модель. ИМХО.

Answer 2

Я узнал в школе, что каждый база данных должна быть объектом в моя модель.

То есть вы не изучали ориентацию объекта? Наследование? Отображение нескольких типов объектов в одну таблицу? Только простая «тупая» каждая таблица - это один объект? Есть более логичные способы сопоставления объектов. Все со своими отличными положительными и отрицательными сторонами (т.е. вы выбираете их в зависимости от обстоятельств, среди них количество полей в каждом объекте).

Также я узнал, что для каждого стола (или объект модели) должен быть DAO создан в DAL.

Иди в школу, потребуй деньги обратно - они были идиотами. Сгенерированные DAO плохи для начала. Становится хуже иметь один на объект. КОНФИГУРАЦИЯ превосходит КОД - универсальный DAO может обрабатывать x различных объектов в зависимости от конфигурации. Много меньше кода для тестирования и загрузки. Вот как это делают правильные фреймворки (например, Hibernate / NHibernate). Вы можете написать DAL, который содержит около полудюжины методов, которые он предоставляет во время операций, и обрабатывает неограниченное количество объектов. В начале вы говорите каждому DAL, какой объект он должен обрабатывать и как, чтобы он мог генерировать правильный SQL и т. Д.

Как лучше всего обращаться с эта проблема Bll?

Снова в школу, основы обучения. Читайте об O / R мапперах. Hibernate / NHibernate (вы не называете используемый язык), Toplink и т. Д.

Если bll нуждается в содержании таблицы из другой таблицы, где это не ответственность за то, что лучший способ получить контент? Иди спроси на ответственный BLL или перейти непосредственно к DAO

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

Читайте о Hibernate / NHibernate.

Хорошей книгой является также "древние" приложения для построения объектов, которые работают "Скотта Эмблера".