MVC Java - не чувствует, что я получаю его
Это было слишком длинно для комментария, таким образом, я должен был сделать его ответом, но это в ответ на ответ B Jeff.
помните, что исходные реализации C++ были просто как предварительный компилятор, которые производят код C для 'реального' компилятора.
у меня есть друг (кто пишет компиляторы C++ - да, множественное число), кто обижался бы к Вашему первому предложению. Компилятор, объектный код которого является исходным кодом C, является столь же очень компилятором как любым другим. Сущность компилятора - то, что он понимает, что синтаксис языка, и генерирует новый код на основе этого. Препроцессор не знает о языке и просто переформатировал свой вход.
Помнят, что компиляторы C, которые скомпилировали бы вывод тех компиляторов C++, самостоятельно произведут код ASM, был бы тогда выполняться через ассемблер.
4 ответа
MVC is an interesting abstraction, but has some problems.
In reality, the controller and view are often paired--even though in theory you should be able to replace either one without the other, in reality the interface mechanisms to different views are so different that the controller & view are combined.
The best description I've seen relating to Java is that the view is your swing components so your portion of the view code is nothing but placing those components on the screen.
Your controller is the rest of that class, the listeners and the rest of your code that interacts with the view.
My suggestion would be to not worry too much about isolating the view and controller, but that said, I am totally behind keeping a very strong separation between the model and the view/controller.
EDIT/Advanced: I have used a pattern where controller and view are isolated and it is more flexible, but it tends to be a lot more work. I think Struts uses the binding model--if you want to see some abstraction techniques you might look there or search for stuff about "binding" swing controls.
Я не думаю, что эта диаграмма очень хорошая и, вероятно, делает вещи намного более запутанными.
Контроллер должен нести ответственность за предоставление модели представлению. Модель не должна содержать ничего, кроме простых средств доступа к вашим данным. Любая потребность во взаимодействии с Моделью - или изменении любого из ее значений - должна происходить через Контроллер.
Таким образом, Представлению нужно только знать, как визуализировать / представить Модель пользователю. Таким образом, любые операции с моделью - такие как saveFavoriteContactsToLocalStorage () - должны быть методами контроллера, а не класса View. Кроме того, Контроллеру не нужна ссылка на View для создания - я думаю, что это приводит к изменению предполагаемого порядка всего шаблона MVC.
Я согласен с Биллом К. Стандартный MVC не так важен при работе с богатым клиентом. Это отличная модель для написания веб-приложений, поскольку события (щелчки в вашем браузере) сильно отличаются от вашего представления (HTML-рендеринг).
Со стандартным графическим интерфейсом лучше всего подходит модель, которая называется PAC (презентация / абстракция / управление). Здесь представление (представление + обработчик событий), контроллер управляет обменом между представлением и абстракцией. А абстракция - это ваша бизнес-модель.
Таким образом, у вас есть контроллер, который управляет связью между частью графического интерфейса (представление + пользовательские события) и вашей абстракцией. У вас есть агент PAC для любого разрабатываемого вами графического интерфейса и четкое разделение между ними.
Еще одна статья о чем-то лучшем, чем MVC, связанном с PAC: HMVC . Довольно старый, но практичный и помогает разобраться.
From my perspective, this is something I ran into when I first tried to separate out my Models, Views and Controllers in my first desktop application.
With Web Applications, the MVC pattern fits VERY naturally because of the innate nature of the web, but unfortunately it's not possible to fit a pure MVC patter to a desktop app, where the Operating system plays an innate role in notifications. This usually leads to the pattern being implemented as you've shown in your diagram.
However the pattern that you've shown really needs to be implemented like this, I think (I've switched over to .NET after a brief affair with Java, so please keep that in mind):
public class ContactManagerMainScreenModel
{
ContactManagerMainScreen v;
// Loading Local Storage
LocalContactStorage LocalContactStorage = new LocalContactStorage();
// Favorite list
boolean showFavoritesList = true;
public void register(ContactManagerMainScreen v)
{
this.v = v;
}
public void ShowOrHideFavoritesList()
{
if(showFavoritesList)
{
showFavoritesList = false;
v.RefreshView(this);
}
else
{
showFavoritesList = true;
v.RefreshView(this);
}
}
}
Meanwhile the controller would be responsible for receiving user actions. So if you have a button that says "Toggle Favorites", this would cause the controller to call _model.ShowOrHideFavoritesList(). The model would update itself and ask the view to refresh itself using it's new state.
The view would now be free from the dependency on the controller.