The title might not be easy to understand but it seems to me it is a basic design question when dealing with smart models.
I have a hierarchy of model objects that represent different types of document.
Say I have a view with different buttons, each one opens the document of the underlying object model. When I click on a button I have to display a view whose controller implementation depends only on the underlying model object class. How do I get this implementation ?
(It could be in the implementation of the button but then the question becomes how do I get the implementation of the button)
Should it be a factory that takes as an input the type of my model and returns my view controller ? Should it be my model that knows how to build its controller (seems dirty nè ?) ? Should I use composition ? Something else ?
I hope I am being clear enough. I am a bit struggling with this !
Your question is too abstract to give a specific advice. MVC pattern appears in many forms and in many technologies. For a web page it will have one shape, for a WPF app it will have another. In general there are both "view-first" and "controller-first" approaches. You can start with any one and see if it comes natural for your problem, if not -- refactor.
One other area you can explore is the area of modern composite application frameworks which provide out-of-the-box modular MVC\MVVM solutions. If you're writing for web, read about ASP.NET MVC and its best practices. If you're writing for WPF, read about MVVM approach and take a look at Prism, for example. You might find that your problem is already solved by existing tools.
Related
I have written python code that analyses two text sources and compares them.
I'd like to implement this dynamically via two text boxes that a user could either type into or manually upload. I have already begun coding this using HTML. Would it be better to implement a widget or the models instead to make the text area boxes?
Edit:
I wrote this question when I was just figuring Django out, so forgive me if it sounds confusing. But everyone starts somewhere. I'm unable to delete the question as contributions have been made already. YouTube courses proved helpful in learning the basics, if any beginners stumble upon this.
You use a form object. Django has form objects (https://docs.djangoproject.com/en/2.0/topics/forms) that take a model and translate it into html elements. So I guess in a way, you implement the model but I want to stress that that's not actually what's happening from a technical standpoint. A better way to say it is that you're implementing forms. The reason I stress this so much is so that you understand what's really going on so that you don't have misunderstandings that end up costing you in code clarity and readability.
So to answer your question, you can implement django forms to do this very easily. The way you implement it depends on your models and how they are designed since the forms use the models to create the right html form elements. If you're dealing with one model that will be instantiated by the form input, create a model form. This will take the input from the form and create your model instance. If you're dealing with one form that uses multiple models, then use a generic form. In this case, you will have to write your own save method that does the actual logic of the form.
One other thing to add... No matter what, your end result will always be a widget on the HTML in the end. Django forms translate a model class into a form element with input elements. If you didn't use Django forms, you would still do the translating, but you would have to do it from scratch.
I hope this helps and that I correctly understood your question.
Today when I searched on the internet I saw the View first approach in web development of Lift framework. Can somebody tell me the differences between view first and MVC approach ?
Thank you very much
View first is based not on a model and a controller, but mostly interested in the view. Many problem domains do not neatly compose in controllers and models. Think about a ecommerce site, the shopping cart exists on all pages, but should every controller control it? Personally in MVC too much of my time is spent thinking about how to logically make the problem fit into MVC than just coding. View first takes away this controller / view / model and instead just has a view which in Lift can call "snippets". It is almost a superset of MVC since if you wanted you could only have a single snippet per page, but Lift allows you to do much more. Snippets can be cross cutting concerns or very page specfic logic.
From the lift website..
Lift is different [from MVC]. For HTML requests, Lift loads the view first and builds your page from the view. Lift also supports REST style requests for non-HTML data. (See 11 on page 1↑) “Why?” Because complex HTML pages rarely contain a dominant piece of logic... a single controller... but contain many different components. Some of those components interact and some do not. In Lift, you define the collection of components to be rendered in the resulting HTML page in the view.
When your using lift, you basically have a view(page) and from this you could incorporate any snippet(app) that you have without much of the antics you'd normally have to do in an MVC framework/environment.
Basically you don't have to choose what the most important thing on the page is just what you want to add to a page and then add it.
I have been developing MVC 3 applications using Razor. I was wondering how much code would be acceptable in my views. There were situation where I needed to create, instantiate and use an object which wasn't included in the model and using ViewModel would make the model object bloated. Now when I look at some of my views, I find them full of server side codes. What would be the best practice when dealing with such issues?
I was wondering how much code would be acceptable in my views.
If by code you mean C# code then there should be exactly 0 to be precise. On the other hand it is perfectly fine to write HTML markup in your views and call HTML helpers.
There were situation where I needed to create, instantiate and use an
object which wasn't included in the model and using ViewModel would
make the model object bloated
Then it seems that your view model was not adapted to this view (since this view requires additional information). So change this situation by adapting the view model to it and including everything that it needs.
Now when I look at some of my views, I find them full of server side
codes. What would be the best practice when dealing with such issues?
Yes, that's horrible. Simply adapt your view models and refactor this code into your view models or controllers or even write custom HTML helpers.
I'm coding a menu, that might look something like this:
I wanted to code this using the MVC pattern. So I started drawing a UML class diagram for the model, and got this:
But I wasn't happy. I couldn't come up with a good interface for the controller to interact with. Then I realized that for example the NumberMenuItem itself could (should) be split up in to a model, a view and a controller. The model would be the number. The controller would be the - and + used to decrement and increment the number. And the view would be the label displaying the current numeric value. The other MenuItem subclasses can also be split up in MVC parts.
So now the question is:
How do I model this now that CommandMenuItem, NumberMenuItem, StringMenuItem, and SubMenuItem are actually MVC triads themselves but on a lower level?
P.S.
The implementation will allow for example a NumberMenuItem to come in the middle of a menu (showing only - # +, i.e. without any descriptive text), but my external API will make sure that NumberMenuItems and StringMenuItems are always the sole item in a submenu, like in the sketch I posted. Might hide the titlebar of the submenu though.
I think I've got something that could work now.
I made lower level MVC triads where the lower level model is part of the bigger model. Same for the controller and view.
Only thing I've been able to find about this on the web is this: http://www.purpletech.com/articles/mvc/mvc-and-beyond.html
Closed. This question is off-topic. It is not currently accepting answers.
Want to improve this question? Update the question so it's on-topic for Stack Overflow.
Closed 9 years ago.
Improve this question
I need to explain to a not-very-technical manager the MVC (model-view-controller) concept and ran into trouble. The problem is that the explanation needs to be on a "your grandma will get it" level - e.g. even the fairly straightforward explanation offered on MVC Wiki page didn't work, at least with my commentary.
Does anyone have a reference to a good MVC explanation in simple terms?
It would ideally be done with non-techie metaphor examples (e.g. similar to "Decorator pattern is like glasses") - one reason I failed was that all MVC examples I could come up with were development related.
I once saw a list of pattern explanations but to the best of my memory MVC was not on it.
Thanks!
How about this - off the top of my head, hopefully it works for you.
MVC can be metaphorically related to a TV. You have various channels, with different information on them supplied by your cable provider (the model). The TV screen displays these channels to you (the view). You pressing the buttons on the remote controls affects what you see and how you see it (the controller).
I was watching TV, so I got some inspiration from there!
I don't trust metaphors. But it's not hard to explain it:
the Model is the part of the code that knows things
the View is the part of the code that shows the things the Model knows
the Controller is the part of the code that gets commands from the user and tells the View what to show and the Model what to know.
The best way I describe it would be:
The Model is the data source. It's your database storage, it's the
code needed to add/remove/update/change the information you
warehouse.
The View is the part the user sees and interacts with. An HTML
page, an application window.
The Controller is the code that marries the View to the Model. If
you clicked a "Delete" button, it handles the business logic and
rules (are you the authorized person to delete? is it a deletable
record, etc).
The View doesn't need to know anything about the Model. The Model doesn't need to know anything about the View. The Controller is what marries the information source (Model) with the output (View).
Think of it in terms of video games. Way back when - there were tons of different video cards and how they worked. Games needed all kinds of code to talk to them. You had to choose what kind of card you had before you could play the game. Game developers had to create code for different video cards.
Along comes something like OpenGL or DirectX -- and it acted as the middle-layer between them. Game developers could write to the DirectX interface -- instead of different card's instruction sets. It freed game developers from having to know about the specific video card. It freed card makers to be able to design to the DirectX instruction set.
In this case - you playing the game is the View, DirectX is the Controller, and the Model is the video card.
M-V-C Think of it as: "Order Details (including Customer & Employee info)", "HTML/ASP Form (to display the OrderDetails)" and "Order details service class (having methods to SaveOrderDetails, GetOrderDetails etc.).
The Model (Data Class e.g. OrderDetails)
The data you want to Display
The Controller (Service class)
Knows about the Model (Order Details)
Has methods to manage the Model
And as such can be unit tested Its Single Responsibility is to manage the OrderDetails CRUD operations.
It knows NOTHING about the View
The View (ASP Page)
Displays the Model (OrderDetail's ViewData).
It has to know about the Model's structure so it can correctly display the data to the users on screen.
The View's structure (style, layout, HTML etc., locale) can be changed at anytime without it changing anything in the application's functionality.
And as such, many Views can display the same Model in many different ways.
In multi-tenant web applications, Customer specific Views can be stored in a database table and displayed based on Customer information
Tell "your grandma" that you are the model (you are doing the work), he is the controller (i.e., middle manager), and the view is like marketing, they get all the credit.