Qt가 모델 / 뷰 용어를 오용하는 이유는 무엇입니까?

Qt가 모델 / 뷰 용어를 오용하는 이유는 무엇입니까?

---

모델 / 뷰 컨트롤과 함께 Qt에서 사용되는 용어에 결함이 있다고 생각합니다. 에 자신의 설명 페이지 그들이보기 및 컨트롤러를 통합하고 다음과 같은 사진을주고있다 의해 MV에 MVC를 단순화하는 것이, 상태 :

하지만 제 생각에는 그들이 사물의 역할을 잘못 명명했다고 생각합니다.

1. 병합 된 컨트롤러가있는 뷰라고 부르는 것은 사실 뷰 전용입니다.
2. 그들이 모델이라고 부르는 것은 사실 컨트롤러입니다.
3. 정말로 모델을 갖고 싶다면 "데이터"가있는 어딘가에있을 것입니다.

앱에서 Qt 모델 / 뷰 구성 요소를 사용하는 일반적이고 건전한 방법에 대해 이야기하고 있습니다. 이유는 다음과 같습니다.

1. 이것은 일반적으로 객체에 특정한 컨트롤러 로직을 추가하지 않고 그대로 사용되는 Qt 구성 요소입니다)
2. 모델과 관련이없는 rowCount, columnCount, data 등과 같은 여러 Qt 메서드를 구현해야하기 때문에 이것은 모델이 아닙니다. 실제로 컨트롤러에는 일반적인 모델 방법이 있습니다. 물론 여기에서 컨트롤러 와 모델 로직을 모두 구현할 수 있지만 먼저 코드 디자인이 상당히 나쁘고 두 번째로 컨트롤러와 뷰가 아닌 컨트롤러와 모델을 병합합니다.
3. 이유 2에서 언급했듯이 모델 로직을 분리하려면 그림의 파란색 상자가 아니라 점선 "데이터"상자 (물론 실제 데이터와 통신)입니다.

Qt의 용어가 잘못되었거나 이해하지 못하는 것은 나뿐입니까? (BTW : 그것이 학문적 질문이 아닌 이유는 제가 그들의 이름에 따라 제 프로젝트를 코딩하기 시작했고 곧 코드가 분명히 옳지 않다는 것을 알게 되었기 때문입니다. 그들이 모델이라고 부르는 것에 모델 로직을 넣지 마십시오)

---

Qt의 이름이 오해의 소지가 있다는 데 동의합니다. 그러나 제 생각에 문제는 Qt만의 문제가 아니라 UI를 구현할 때 관심사 분리 원칙을 고수 할 수있는 모든 프레임 워크에서 공유됩니다 . 누군가가 그러한 프레임 워크를 생각해 내고 "사물"을 분리 할 수있는 좋은 방법을 찾으면 항상 "모델"이라고 부르는 모듈과 "보기"라고 부르는 다른 모듈을 가져야한다는 의무감을 느낍니다. 수년 동안 나는 다음 프레임 워크로 작업했습니다.

• MFC
• Qt
• 그네
• SWT
• MVVM을 사용하는 WPF

이러한 프레임 워크에서 "모델"과 "보기"라는 용어가 사용되는 방식과 "보기", "모델"및 "컨트롤러"(있는 경우)의 클래스가 갖는 책임을 비교하면 매우 큰 차이가 있음을 알 수 있습니다. 다른 개념과 용어를 비교하는 것은 확실히 유용 할 것입니다. 그래서 한 프레임 워크에서 다른 프레임 워크로 전환하는 사람들이 제정신을 유지할 수있는 기회를 가지지 만 많은 작업과 연구가 필요합니다. 좋은 읽기는 Martin Fowler의 개요 입니다.

MVC 패턴이 어떻게 생겼는지에 대한 아이디어가 너무 많기 때문에 어느 것이 맞습니까? 제 생각에는 MVC를 "올바르게"구현해야하는 방법을 알고 싶을 때 MVC를 발명 한 사람들을 찾아야합니다. 에서 원래 스몰 토크 용지 는 말합니다 :

보기는 해당 애플리케이션에 할당 된 비트 맵 디스플레이 부분에 대한 그래픽 및 / 또는 텍스트 출력을 관리합니다. 컨트롤러는 사용자의 마우스 및 키보드 입력을 해석하여 모델 및 / 또는보기를 적절하게 변경하도록 명령합니다. 마지막으로 모델은 애플리케이션 도메인의 동작과 데이터를 관리하고, 상태에 대한 정보 요청에 응답하고 (일반적으로보기에서) 상태를 변경하라는 명령에 응답합니다 (일반적으로 컨트롤러에서).

In light of that I would answer your three main concerns thusly:

1. In fact a Qt component "manages the graphical [...] output", and "interprets the mouse and keyboard inputs", so it could indeed be called merged View and Controller with respect to the definition above.
2. I agree that you are/would be forced to merge Controller and Model (again with respect to the definition above).
3. I agree, again. The Model should only manage the data of the application domain. This is what they call "data". Clearly, dealing with rows and columns for example has normally nothing to do with our applications domain.

Where does it leave us? In my opinion, it is best to figure out what Qt really means when the terms "Model" and "View" are used and use the terms in their manner while we are programming with Qt. If you keep being bothered it will only slow you down, and the way things are set up in Qt does allow elegant design - which weighs more that their "wrong" naming conventions.

---

Short answer

Qt's MVC only applies to one data structure. When talking about an MVC application you should not think about QAbstractItemModel or QListView.

If you want an MVC architecture for your whole program, Qt hasn't such a "huge" model/view framework. But for each list / tree of data in your program you can use the Qt MVC approach which indeed has a controller within its view. The data is within or outside of the model; this depends on what type of model you are using (own model subclass: probably within the model; e.g. QSqlTableModel: outside (but maybe cached within) the model). To put your models and views together, use own classes which then implement the business logic.

---

Long answer

Qt's model/view approach and terminology:

Qt provides simple views for their models. They have a controller built in: selecting, editing and moving items are something what in most cases a controller "controls". That is, interpreting user input (mouse clicks and moves) and giving the appropriate commands to the model.

Qt's models are indeed models having underlying data. The abstract models of course don't hold data, since Qt doesn't know how you want to store them. But you extend a QAbstractItemModel to your needs by adding your data containers to the subclass and making the model interface accessing your data. So in fact, and I assume you don't like this, the problem is that you need to program the model, so how data is accessed and modified in your data structure.

In MVC terminology, the model contains both the data and the logic. In Qt, it's up to you whether or not you include some of your business logic inside your model or put it outside, being a "view" on its own. It's not even clear what's meant by logic: Selecting, renaming and moving items around? => already implemented. Doing calculations with them? => Put it outside or inside the model subclass. Storing or loading data from/to a file? => Put it inside the model subclass.

---

My personal opinion:

It is very difficult to provide a good and generic MV(C) system to a programmer. Because in most cases the models are simple (e.g. only string lists) Qt also provides a ready-to-use QStringListModel. But if your data is more complex than strings, it's up to you how you want to represent the data via the Qt model/view interface. If you have, for example, a struct with 3 fields (let's say persons with name, age and gender) you could assign the 3 fields to 3 different columns or to 3 different roles. I dislike both approaches.

I think Qt's model/view framework is only useful when you want to display simple data structures. It becomes difficult to handle if the data is of custom types or structured not in a tree or list (e.g. a graph). In most cases, lists are enough and even in some cases, a model should only hold one single entry. Especially if you want to model one single entry having different attributes (one instance of one class), Qt's model/view framework isn't the right way to separate logic from user interface.

To sum things up, I think Qt's model/view framework is useful if and only if your data is being viewed by one of Qt's viewer widgets. It's totally useless if you're about to write your own viewer for a model holding only one entry, e.g. your application's settings, or if your data isn't of printable types.

---

How did I use Qt model/view within a (bigger) application?

I once wrote (in a team) an application which uses multiple Qt models to manage data. We decided to create a DataRole to hold the actual data which was of a different custom type for each different model subclass. We created an outer model class called Model holding all the different Qt models. We also created an outer view class called View holding the windows (widgets) which are connected to the models within Model. So this approach is an extended Qt MVC, adapted to our own needs. Both Model and View classes themselves don't have anything to do with the Qt MVC.

Where did we put the logic? We created classes which did the actual computations on the data by reading data from source models (when they changed) and writing the results into target models. From Qt's point of view, this logic classes would be views, since they "connect" to models (not "view" for the user, but a "view" for the business logic part of the application).

Where are the controllers? In the original MVC terminology, controllers interpret the user input (mouse and keyboard) and give commands to the model to perform the requested action. Since the Qt views already interpret user input like renaming and moving items, this wasn't needed. But what we needed was an interpretation of user interaction which goes beyond the Qt views.

---

The terminology isn't right or wrong, it's useful or useless.

You might change the question a bit and ask why Qt isn't more MVC-friendly. The answer to is that the early Qt developers believe that decoupling V from C in GUI applications makes for bad Vs and Cs both. QWidget's design tries to make it simple to bind mouse input interperation closely with pixel output decisions, and you can see how that's not the road towards MVC.

---

As Model function is to respond to requests for information, I think there is nothing wrong in defining such methods as rowCount, columnCount, etc. I think Model is some kind of wrapper for data source (no matter what is it SQL table or just an array), it provides data in standard form, and you should to define methods depends on your data source structure.

---

I believe their terminology is correct...although in real applications I find it can be very easy to blur the lines between model, view, and controller depending on your level of abstraction: one level's view may be a higher level's model.

I feel the confusion arises from their QAbstractModelItem class. This class isn't a model item, but rather it is an interface to a model. To make their view classes interface with the model, they had to create a generic abstract interface to the model. However, a model can be a single item, a list of items, a table of 2 or more dimensions of items, etc; so their interface has to support all these model variations. Admittedly, this makes the model items fairly complex, and the glue code to make it work with an actual model does seem to stretch the metaphor a bit.

참고 URL : https://stackoverflow.com/questions/5543198/why-qt-is-misusing-model-view-terminology