我更喜欢的一种MVC的理解

这个是MVC的最大众化的理解。 但是我后来还是更喜欢最近发现的另一种解释。

Model -- Data only. Get methods, setmethods, etc. It is isolated -- it knows nothing about the View, nor theController.

 

View -- UI only. Dumb or"humble". Only shows what you tell it to, and never performs anytransformation or validation logic -- e.g., it always forwards input via anevent/callback system. It is isolated - it knows nothing about the Model, northe Controller.

 

Controller -- Sits between Model andView. Does any data transformation (business logic) that is necessary to getthe data from the Model to the View. Does most data validation on input thatcomes back from the View. It "knows" about both the View and theModel.

 

With this definition it becomes mucheasier to divvy up work between engineers. If someone is a database engineer,they probably don't know UI. But they can write the Model to great effect, andhey maybe they can stub out a crappy-and-simple View. Maybe it's simply a textdump of the data, that's fine. At least the code-level interface is in place.Then the UI developers can come and write the Controller and View. Then whenthe UX designers change what they want the UI to look like, you can eitherchange the View or write a new one. Or if you want to use different UItechnologies -- WinForms on XP, WPF on Vista, or Cocoa on MacOS, then just havedifferent View implementations for each. Things like skinning are then easilyisolated to the View pillar.

 

The other useful pattern to employ hereis an Inversion of Control (IoC) container/scope object. None of the classesparticipating in MVC need to know about the specific implementation of eachother, just the interface/contract. This makes it trivial to unit test theController with faked out View and Model implementations. The Controller justsays, "hey Create me an instance of I____View" ... and your unit testharness just happens to be providing it the Mock____View instead of the____View that is used in production.

也就是说 View <--> Controller <--> Model