Tag Info

New answers tagged

1

Here is what you've done wrong already -- you have hand-rolled an MVC while in a state of confusion, and without any MVC under your belt. Take a look at PureMVC, it is language agnostic and can be a good platform to get your feet wet with actually doing MVC. Its code is small and comprehensible, and this will allow you to tweak it to your needs as you ...


0

So to me MVC is all about project structure, and here's how I break down MVC. M for Model: This is everything that has to do with data. From your Core Data, to your network calls, to objects that reformat or translate data to get it ready for the app. Basically where all the cool logic goes. V for View: This area if for stuff that directly interacts with ...


0

After some thought it seems like the following approach might be beneficial whereby each inner control is represented by a facade which constructs the presenter, view and its model and exposes the relevant methods: I would love to know what others think about this idea...


-1

I suggest you the "book" I am writing about MVC. It's far from complete, but it may give you an idea. MVC on the web is a strange beast, however. If you check most resources, they will present MVC for a GUI, but on the web you have a different structure: the View is isolated from the Model and the Controller, can only push requests, and the communication ...


0

I learnt about this once but not from a book.. but hopefully this is not inaccurate. MVC stands for Model, View, Controller. The View is the GUI The model is most of your program, and the controller is part of your program that interfaces between your model and your GUI/view. The benefit to that is that e.g. if there is a sudden change in requirements, ...


2

The idea is simply to create a clear separation between business logic and the UI. The Model is the data and the business logic of the application. The View is UI logic, and creates a visual representation of the Model. The Controller is mediating between the two to keep them loosely coupled. Here's an example to help you understand. This relates more to ...


10

Model The model represents the domain you are trying to model, and also encapsulates the business logic of your application. For example, using the good old blog example, think about all the things your make up your blog: Posts, Comments, Tags, Categories, Authors, Commentors, Editors, Feeds, etc. This is your domain, and depending on which of those you ...


12

I'm going to try to explain this with an example. Lets say you want to build a website that shows people a list of friends. So it starts with a list of your friends (A,B,C..). When you select one, it shows a list of their friends (A1, A2, etc) and so on. The "View" is an implementation of what the user can see. In this case, we need only one view i.e. a ...


-2

Models are essentially objects that wrap databases, and instances of those models are essentially objects that wrap rows in the database. Model instances have functions that allow them to change their internal state and interact with other model instances of a different type. This is where most of your business logic should live. Controllers are essentially ...


1

Well, let's evaluate what you are asking first. Your application is currently a Model-View-Controller application. What does that mean? It means your application has: A Presentation layer, the View, An Application Processing Layer, the Controller, and A Data Management Layer, the Model. What would it take to convert it to N-tier? Well, according to ...


0

Let's look at some questions I ask when I am building a website: Do you expect your website to grow in either views or complexity? Do you expect there to be more "pages" in the future? Do you know that you will need a data provider on the back end at some point in the future, even if not currently? Will you have other developers working on this site, ...


0

There is no right answer. You will probably be going back and forth between models and templates before you settle on something which works. You should start of with use-cases or usage scenarios which include the view templates. As you write those, you will expose some system concepts, many of which will become your core models. Once you see what is ...


2

EEK... nooo my friend, hiding controls is the last thing you should do. If your using MVC, and I assume (Judging by your description) the Model Binding syntax, where your forms are generated using Razor and the HTML Helpers, then your already half way towards letting MVC do all the work for you. There are 2 main strategies when it comes to ASP.NET MVC. ...


1

1) The page that will be displayed contains MANY anchor tags, if that's embedded in an iFrame, what happens if the user on THEIR website clicks the link in the iFrame? Does the iFrame page change, or does their ENTIRE page change? Iframes are self-contained websites. As such, any links inside the iframe will change only the contents of the iframe, ...


0

The Model is your data: teachers and classes. Your Controller, among other things, composes the model data in such a way that the View can easily digest and display it. Composing a ViewModel is a good way to do this if the logic behind displaying the data is complex. Your View takes the data that the Controller has prepared for it, if any, and renders it. ...


0

Business rules are a pervasive responsibility of the application. The view should prevent the creation of conflicting schedules by not allowing them as an option; the controller should identify interactions and prevent their being formed in conflict. The model should prevent storage of conflicting schedules. While you have an overarching rule ("no ...


5

Within the context of the MVC pattern, the Controller and View components are only concerned with user interactions (the Controller with reacting to requests and the View with presenting the UI). All other code, including the business logic and database access goes in the Model component. As the Model is usually quite large, it should have an additional ...


0

My preferred responsibility by object: Controller handles the building of the viewmodel/viewbag. Logic unrelated to the rendering of the page gets shipped off to the BL. Thus personally I would compose the viewmodel within the controller, and not create a separate layer. The layer that you would create to compose the viewmodel, what would you call it? The ...


2

For me there is no question to be answered here, you should always strive to separate out your components as much as possible. At a bare minimum, for every new project I create I do the exact following steps: 1) Create a blank visual studio solution 2) Add an MVC project to it 3) Add a class library to it called the Business layer 4) Add a class library to ...



Top 50 recent answers are included