Я работаю в компании, которая предоставляет изготовленной на заказ 'CRM подобное ' программное обеспечение. Мы в настоящее время перепроектируем/перестраиваем программное обеспечение с надеждами, что это будет выглядеть более современным и будет легче разработать и настроить для будущих клиентов. В настоящее время требуется много времени для настройки каждого нового приложения.
Существует предположение, что причина, она занимает много времени, из-за логики торгового оборота, которая присутствует в слое 'представления'. В некоторой степени я могу ручаться за этот являющийся верным, но признаки не всегда надежно указывают на причину. Было предположение что, если мы просто перемещаем бизнес-логику в слой контроллера и используем чистое представление (мы используем java J2EE и распорки) как в реализации тегов распорок вместо того, чтобы назвать бобовый слой и выполнить итерации объектов прямо на jsp - и т.д. и т.д.
Прежде чем я начну защищать, мы продвигаемся с этим, я хотел получить чувство для того, что думали другие люди. "Чистая" реализация MVC (особенно акцент на отделение контроллера и представления) обеспечивают инструмент для очистки, легче разработать и изменить кодовую базу?
Благодарите всех Вас для входа - который помог много
Ваша цель должна заключаться в том, чтобы собрать всю бизнес-логику в одном месте. По моему опыту, если вы сможете это сделать, вашу кодовую базу будет легче разрабатывать, поддерживать и изменять.
Модель-вид-контроллер - это способ достичь этой точки, хотя в классическом MVC бизнес- логика находится в (доменной) модели, а логика приложения - в контроллере.
Прикладная логика: если дата следующей проверки пользователя находится в пределах недели (или просрочена), покажите экран "запланировать проверку", в противном случае покажите экран "история проверок".
Бизнес-логика: рестораны, которые ранее не прошли проверку, должны проверяться каждые шесть месяцев, рестораны морепродуктов должны проверяться каждый год, а все остальные рестораны должны проверяться каждые два года. Учитывая последнюю инспекцию этого ресторана, когда должна быть проведена следующая инспекция?
.Я работаю в компании, которая довольно строго следует MVC, и у нас большой успех с этим. Мы смогли разработать основные сервисы, которые находятся в контроллере, и повторно использовать их в нескольких проектах. Уровень контроллера также облегчает модульное тестирование и повторное использование кода.
MVC предлагает разделить интеллект надлежащим образом. Это означает, что представление и модель будут тупыми, а контролер - действительно умным парнем. Этот вывод позволяет нам плавно создавать модифицирующих тупиц и умных парней. Эти преимущества в огромной степени извлекаются, когда требования / исправления кода эффективно выполняются. Добавленные абстракции - это боль, пока вы не разберетесь с используемыми шаблонами. Это MVC на стороне сервера. А как насчет MVC в коде на стороне клиента?
Иногда бывает очень верно, что модели представления имеют другой встроенный интеллект и закодированы в бизнес-делегатов. Однако лучше использовать собственные теги. Самая неприятная вещь о страницах jsp для меня возникает, когда они смешивают javascript с кодом. Этот умный код фактически пытается манипулировать DOM и приводит к несопоставленным тегам в статическом коде jsp.
Поскольку у вас есть возможность начать с нуля. Жизнь была бы проще, если бы все использовали ненавязчивый javascript (язык отличный от java и более простой, чем то дерьмо, которое я видел в производственном коде) и настраиваемые теги (не так уж сложно). Еще одна проблема - отсутствие html / css, совместимого с W3C. Огромный помощник по устранению проблем с браузером, если вы такие, какие они есть.
PS: Прошу прощения за длинную тираду :)
Кто-то сказал следующее:
«Любая проблема в информатика может быть решена с помощью другого уровня косвенного обращения »
Но я не помню, кто является автором этой цитаты. Кто-нибудь знает?
Развязка всегда делает это. Неважно, MVC или нет, чем меньше связи в системе, тем проще ее поддерживать и изменять. MVC - это просто хороший шаблон для Интернета, который упрощает разделение, вот и все.