в MVC/MVP/MVPC, куда Вы помещаете свою бизнес-логику?
Это действительно не очевидно.
Прежде всего, оператор == просто сравнивает два указателя. Поскольку a и b являются отдельными объектами, расположенными на разных адресах памяти, a == b вернет false (Привет, пуристы Java, я знаю, что == действительно сравнивает идентификаторы объектов. Я просто пытаюсь дидактический).
Теперь давайте посмотрим на реализацию массивов equals():
boolean[] c = new boolean[] { false, true, false };
boolean[] d = new boolean[] { false, true, false };
if (c.equals(d)) {
System.out.println("Equals");
} else {
System.out.println("Not equals");
}
Это будет печатать Not equals, потому что никакой экземпляр массива фактически не реализует equals() метод. Итак, когда мы вызываем <somearray>.equals(<otherarray>), мы на самом деле вызываем метод Object.equals(), который просто сравнивает два указателя.
Тем не менее, обратите внимание, что ваш код на самом деле делает это:
boolean[] a0 = new boolean[] { false, true };
boolean[] a1 = new boolean[] { true, false };
boolean[] b0 = new boolean[] { false, true };
boolean[] b1 = new boolean[] { true, false };
boolean[][] a = new boolean[][] { a0, a1 };
boolean[][] b = new boolean[][] { b0, b1 };
if (Arrays.equals(a, b) || a == b)
System.out.println("Equal.");
else
System.out.println("Different.");
Arrays.equals(a, b) в конечном итоге вызовет a0.equals(b0), который вернет false. По этой причине, Arrays.equals(a, b) также вернет false.
Таким образом, ваш код напечатает Different., и мы пришли к выводу, что Java-равенство иногда может быть сложным.
5 ответов
Это - то, как я вижу его:
контроллер для прикладной логики; логика, которая характерна для того, как Ваше приложение хочет взаимодействовать с доменом знания, которому это принадлежит.
модель для логики, которая независима от приложения. т.е. логика, которая допустима во всех возможных приложениях домена знания, которому это принадлежит.
Следовательно почти все бизнес-правила будут в модели.
я нахожу полезный вопрос спросить меня, когда я должен решить, куда поместить некоторую логику, "это всегда верно, или только для части приложения я в настоящее время кодирую?"
Путем у меня есть своя структура приложения MVC ASP.NET, рабочий процесс похож на это:
Контроллер-> Сервисы-> Репозитории
уровень Services выше - то, где вся бизнес-логика происходит. При помещении бизнес-логики в уровень Controller Вы теряете способность снова использовать ту бизнес-логику в других контроллерах.
Я не полагаю, что это принадлежит контроллера, потому что, после того как это встраивается там, это не может выйти.
я думаю, что MVC должен иметь введенный промежуток другого слоя: уровень служб, который отображается на варианты использования. Это содержит бизнес-логику, знает о единицах работы и транзакциях, и имеет дело с моделью, и персистентность возражает для выполнения ее задач.
контроллер имеет ссылку на сервис, что это должно выполнить свой вариант использования. Это волнуется о немаршалинге запросов в объекты, с которыми сервис может иметь дело, называет сервис и упорядочивает ответ для передачи обратно представлению.
С этим расположением, сервис применим самостоятельно даже без пары контроллера/представления. Это может быть локальным или удаленным объектом, упакованным, и развернуло любой способ, которым Вы желаете, что контроллер имеет дело с.
контроллер теперь становится связанным более тесно к представлению. В конце концов, контроллер, который Вы будете использовать для рабочего стола, вероятно, будет отличаться, чем тот для веб-приложения.
я думаю, что этот дизайн более для обслуживания широкого круга запросов.
Можно поместить его в два места. Контроллер и на Уровне представления. При наличии части логики на Уровне представления можно ограничить количество запросов назад в архитектуру, которая добавляет загрузку в систему. Да, необходимо кодировать дважды, но иногда это - то, в чем Вы нуждаетесь для быстро реагирующего пользовательского опыта.
я отчасти как то, что было сказано здесь ( http://www.martinhunter.co.nz/articles/MVPC.pdf )
"С MVPC, компонент предъявителя модели MVP разделяется на два компонента: предъявитель (просматривают управляющую логику), и контроллер (абстрактная управляющая логика цели)".
Обязательно вставьте в модель!
Конечно, часть взаимодействия с пользователем должна быть в представлении, которое будет связано с вашим приложением и бизнес-логикой, но избегайте этого, насколько это возможно. По иронии судьбы, следование принципу «делать как можно меньше», поскольку пользователь «работает» в вашем графическом интерфейсе и столько же во время «отправки» или запросов действий делает лучший пользовательский интерфейс и удобство использования, а не наоборот . По крайней мере, для бизнес-приложений.