Как использовать BLL, DAL и модель?
В моей компании я должен использовать слой Bll, Dal и модель для создания приложений с базой данных.
В школе я узнал, что каждая база данных должна быть объектом в моей модели. поэтому я создаю всю модель моей базы данных. Также я узнал, что для каждой таблицы (или объекта модели) в DAL должен быть создан DAO. Так что я делаю это для.
Теперь я застрял в классах BLL. Я могу написать BLL class для каждого DAO/ModelObject или я могу написать BLL class, который объединяет некоторые (логические) DAO... Или я могу написать только один Bllclass, который будет управлять всем. (это последний, я уверен, что это не лучший способ..)
Какова лучшая практика для решения этой проблемы?
И второй вопрос. Если bll нуждается в содержании таблицы из другой таблицы, за которую он не отвечает, каков наилучший способ получить содержимое? Иди спроси на ответственном BLL или иди прямо в ДАО?
Я борюсь с этими вопросами последние 2 месяца, и я не знаю, как лучше всего с ними справиться.
2 ответа
Вы должны начать с того, что вам нужно, чтобы работало приложение.
Например: "Мне нужен веб-интерфейс для входа пользователя"
- Поэтому мне нужен контроллер, который использует модель для проверки псевдонима и передачи
- Тогда мне нужен объект bll, чтобы сделать логику для проверки псевдонима и передать
- Затем мне нужен объект dal для доступа к базе данных для получения информации о пользователе
Если вы не начнете так думать (подход сверху вниз), то вы напишите много кода, который никогда не будет использоваться.
примечание: если dal является картированием orm или нет, анекдотично. Также, если модель использует bsl или bsl, используйте модель. ПО МОЕМУ МНЕНИЮ.
В школе я узнал, что каждая база данных должна быть объектом в моей модели.
Значит, ты не изучил объектную ориентацию? Наследование? Отображение нескольких типов объектов в одну таблицу? Только простая "тупая" каждая таблица - это один объект? Есть более логичные способы сопоставления объектов. Все со своими разными хорошими и плохими сторонами (то есть вы выбираете их в зависимости от обстоятельств, среди них количество полей в каждом объекте).
Также я узнал, что для каждой таблицы (или объекта модели) в DAL должен быть создан DAO.
Иди в школу, потребуй деньги обратно - они были идиотами. Сгенерированные DAO плохи для начала. Становится хуже иметь один на объект. КОНФИГУРАЦИЯ превосходит КОД - универсальный DAO может обрабатывать x различных объектов в зависимости от конфигурации. Много меньше кода для тестирования и загрузки. Вот как это делают правильные фреймворки (например, Hibernate / NHibernate). Вы можете написать DAL, который содержит около полудюжины методов, которые он предоставляет во время операций, и обрабатывает неограниченное количество объектов. В начале вы говорите каждому DAL, какой объект он должен обрабатывать и как, чтобы он мог генерировать правильный SQL и т. Д.
Какова лучшая практика для решения этой проблемы?
Снова в школу, обучение основам. Читайте об O / R мапперах. Hibernate / NHibernate (вы не называете используемый язык), Toplink и т. Д.
Если bll нуждается в содержании таблицы из другой таблицы, за которую он не отвечает, каков наилучший способ получить содержимое? Иди спроси на ответственном BLL или иди прямо в ДАО?
Зависит от архитектуры. В общем, бизнес-объект будет приходить с фабрики, и разговаривать нужно только с фабрикой. Затем фабрика будет иметь дело с DAL - после и до выполнения действительно интересных вещей, таких как кэширование.
Читайте о Hibernate / NHibernate.
Хорошей книгой является также "Скотт Эмблер", "Древние приложения для создания объектов, которые работают".