Geek Answers Handbook

MVP (Model Viewer) or MVC (Model Viewer)

I already know the difference between MVP and MVC. Then, after going through the SRS application, I get a fix that needs to be selected, applied and used as the Applcation architecture. In my opinion, I would choose MVP, where there is a chance to use the same business logic from more than 2 graphical interfaces. As for the application with public (www) and Adming (winform) part. If not, look for MVC. Because I can more closely follow Factory patterns.

Deeds, I don’t know, but it seems to me that I just play blindly if I have to choose among them. I need to know. What is your opinion on this?

Note. I follow .net and C #.

+7
design design-patterns architecture
source share
2 answers

In my opinion, the differences for all variants of Model View Controller models ( MVP , Passive View , Controller Control , Model View, etc. ) are quite subtle. It's all about who processes the data and takes data from anyone, really. They all try to solve the same problem by separating something from another thing, and the solutions do it all in a similar way.

It is clear that the concepts are similar in implementation when you think about it in visual terms:

Simplistic MVC: +-------+ manipulates data | Model |<---------------------+ +-------+ | | | | gets data | v | +------------+ serves data +------+ | Controller |------------->| View | +------------+ +------+ Simplistic MVP: +-------+ | Model | +-------+ | ^ | | get/manipulates data v | +-----------+ serve data +------+ | Presenter |-------------->| View | | |<--------------| | +-----------+ tell changes +------+

They are similar in that the class hierarchy may look the same in both. However, the difference lies in different ways of displaying and processing data. When you roll out your own MVC, you are responsible for how it should look.

In fact, this is not so important, since they are all based on the principle of separating code fragments into independent logical entities and reducing code duplication. As long as you keep the combination code low it should work well, after all. This only matters if you want to be a dogmatic consequence of your application architecture.

Be pragmatic about this and do what works best for your needs, as you will get the mixture anyway. It should be “pretty” easy to switch between options depending on what you need to view. Follow SOLID principles and you should do your best. (See Also About SOLID .)

I would suggest you study if there are MVC or MVP frameworks to see how this is done.

+17
source share

I think you're on the right track. MVP for applications with more than one GUI and MVC for web applications is my general guide. If you do one of them, I would use an infrastructure like ASP.Net MVC or Castle MonoRail, because plumbing itself can be a pain. There is a good MVC reference implementation here based on the Northwind database that ships with SQL Server 2000.

http://nsk.codeplex.com/SourceControl/list/changesets

+1
source share

More articles:


All Articles