Каков распространенный способ для дизайна Шаблона ООП (Доступ к данным)
Вам необходимо изменить название вашего проекта. Согласно вашему composer.json ваш проект yiisoft/yii2, что не соответствует действительности. Я понятия не имею, как вы получили это composer.json, вот официальный шаблон - структура вашего приложения и composer.json должны выглядеть аналогично (в качестве альтернативы вы можете попробовать расширенный шаблон ). После изменения имени пакета эта команда должна сделать свое дело:
composer require yiisoft/yii2-queue --update-with-all-dependencies
5 ответов
Я использовал Ваше решение в прошлом и единственную проблему, с которой я столкнулся, то, что "Общие" или "статические" методы не поддерживают наследование. Когда Ваше приложение растет, Вы, возможно, очень хорошо должны были бы поддерживать различные типы "OrderControllers".
estabilished способ поддерживать другой OrderControllers был бы, в теории, для создания фабрики:
OrderControllerFactory.ConfiguredOrderController().GetOrder(42);
Проблема здесь: какой тип возвращается "ConfiguredOrderController ()"? Поскольку это должно иметь статический "GetOrder (международный идентификатор)" метод - и статические методы не поддерживаются наследованием или интерфейсами. Путь вокруг этого не состоит в том, чтобы использовать статические методы в классе OrderController.
public interface IOrderController
{
Order GetOrder(int Id)
}
public class OrderController: IOrderController
{
public Order GetOrder(int Id)
{}
}
и
public class OrderControllerFactory()
{
public IOrderController ConfiguredOrderController()
{}
}
Следовательно, Вы, вероятно, будете более обеспечены при помощи нестатических методов для контроллера.
Я думаю, что существует несколько альтернатив, перечисленных в этой превосходной книге: Шаблоны Архитектуры приложений для предприятия. Некоторые шаблоны, которые могут представлять интерес для Вас:
Хорошо Ваше приложение не должно инстанцировать отдельных версий слоя доступа данных, таким образом, у Вас есть это под управлением. Psuedo кодируют Вас отправленный, действительно твердо читать все же.
Вопрос, каков Ваш уровень доступа к данным, и сколько там? Это собирается продиктовать хороший бит того, что Вы делаете. Если Ваше сохранение в файл затем, я думаю, что Вы записали, прекрасно, и если необходимо совместно использовать его с другими контроллерами в системе, возможно перенести объект в одиночный элемент (дрожь).
Если Вы действительно делаете обработку заказов и сохраняетесь назад к базе данных, я лично думаю, что пора посмотреть на ORM. Эти пакеты обработают аспекты CRUM для Вас и сократят количество объектов, которые необходимо поддержать.
Мои.02$, и я оставляю за собой право пересматривать мой ответ, после того как я вижу лучший пример.
Я не могу говорить с деталями VB, потому что я не разработчик VB, но:
То, что Вы делаете, является известной хорошей практикой, разделяя GUI/уровень представления от слоя данных. Включая реальный код приложения в событии GUI методы (печально также известен) плохая практика.
Ваш класс контроллера напоминает шаблон "мост", который является также хорошей идеей, если оба слоя должны смочь изменить свою форму без другого знания об этом.
Вперед!
Это - хорошая практика - особенно, когда Вы добираетесь до точки, где Контроллер должен будет сделать больше, чем простая делегация базового DAL.