I'm still just getting into MVC, and for my first real project I plan on creating a blog. This will be extremely basic (at least at first). Everything I need is going to be on the same page. Here are the initial features I am shooting for:
User should be able to log in, but not register (I will be the only one able to post, and I added myself directly to the DB.
Blog posts should be listed in descending order with a Title, a post date, and the body. No comments required for now.
The bottom of the page will always have an area to make a new post, assuming you're logged in.
Since I'm still new to the MVC structure, I'd like some advice on how it should be organized.
For my models, I figured I should have a post repository and a BlogPost class for the post data which can be used for both the posting and retrieving. I would also need a class for the user.
When it comes to controllers I'm a bit less confident. Should I have a different controller for every type of action? For example, posting should have a controller, retrieving should have a controller, logging in should have a controller, etc?
As for the views, since I really only need a single page, should I only have a single view and have that view output the appropriate content from my controllers?
Just let me know if I'm on the right track, I suppose. If my thought process is way off, please tell me. I've just started working my way through Steven Sanderson's MVC 2 book, but I feel like I need to go out on my own and play between my reading sessions.
Thanks.
Controllers should be grouped by functionality. You could also have a controller per resource (REST). You could have an AuthenticationController which handles authentication and PostsController which will handle the posts retrieval and adding a new post. As far as the views are concerned assuming you will have a single page that will list posts and add new posts you could have a single view but maybe with multiple partial views/editor/display templates.
Related
I'm new to MVC and I've looked through a number of resources but not found any complete help so here's my understanding of what I'm trying to achieve:
I have a Model called 'Company' where each company will have a name, address, email and contact number.
I've been told this is a bit high-level as a model, something I don't really understand why..
As for my actions what should they be - add company, edit company, delete company? - Basically whatever actions are required by the user?
I don't see any problem. As always it depends on your scenario. If you are creating an app to manage companies, then your model seems ok to me. If you were a moving company, and moving companies from one place to another, maybe the Address can also be an entity in your model as it is part of your core and can contain more level of detail.
The same about the actions, add, edit, delete are good candidates. Controller receive these actions, modify the Model, and these changes are also reflected in the View.
MVC itself is a broad concept. Its meaning is more or less clear but it has been adapted to different kind of applications (i.e. web apps where it was often called Model 2).
Inside the controller Company, If you need to add company details, Inside view place your target controller as "Company" and Action as "AddCompany".
By clicking on submit button, the control directly navigates to "AddCompany" Action inside, "Company" controller.
According to that you can add company details into database.
Similar scenario for Edit/Update/Delete company.
Regards,
Pavan.G
Since your new to MVC and have not yet found any complete resource, i recommend you to watch Scott Allen`s videos on asp.net mvc 3 which start from the scratch and move up to the advanced level. It covers almost everything in MVC for beginners and should clear most of your doubts, here is the link below
http://pluralsight.com/training/courses/TableOfContents?courseName=aspdotnet-mvc3-intro&highlight=scott-allen_mvc3-building-intro!scott-allen_mvc3-building-controllers!scott-allen_mvc3-building-security!scott-allen_mvc3-building-infrastructure!scott-allen_mvc3-building-ajax!scott-allen_mvc3-building-deploy!scott-allen_mvc3-building-views!scott-allen_mvc3-building-data-ii!scott-allen_mvc3-building-tdd!scott-allen_mvc3-building-data-i-2#mvc3-building-intro
Hope This helps!
The common situation when developing a website is to have one index action that lists and creates multiple different resources.
For example, lets say that you have transactions controller that lists both payments and expenses on same page (where expense is an auto-calculated group of payments).
On transactions index action, there are two forms: one for creating new expense, and the other for creating new payment. Both of these forms point to submits to their respective controllers create action. If the data is invalid, it should redirect back to transactions#index and display error messages.
This is just a general discussion, it is not related to specific problem, so lets assumpt the following:
No AJAX will be used
We cannot generalize expenses and payments into shared base
The problem is that while we can submit data to different controller, we can't get response from it. We can redirect back, but then we'll loose our data and validation errors. There are some 'hackish' solutions to this, but I would like to keep this simple.
One way of solving this would be to implement specific actions on transactions controller (like create_expense and create_payment). It would work, but it would cause code duplication and breaking of REST and I dont like it.
The real question is: how can we re-use controller actions from various other places in website, and make it feel like a natural process?
You could include a hidden_field :redirect_back_to => transactions_path in your forms, and then just post the forms to their respective controllers, and let the controllers redirect back to params[:redirect_back_to] if it's present.
This might seem a bit hacky, but I think it's the easiest solution if you don't want to use AJAX.
I'm trying to learn the asp.net mvc. I have worked with most of the samples that MS have published.
Most of the samples is just about CRUD.
I'm pretty good at working with webforms, but now I kind of miss the old easy world.
But, my question is: I have a detail page that is connected to an order, I have the order details comming along all well. I got my order detail lines kind of work. But now I would like to do different things with this order, like add more order lines, change the order status with a button, email the order and so on. In webforms I just added eventhandlers on the click event, but here... Do I need multiple forms? How do I make serverside code for example when someone wants to change the orderstatus with a click of a button?
Hi i can recomend you Pro ASP.NET MVC 2 Framework book by Steven Sanderson
I'd recommend you go through the entire NerdDinner tutorial.
But to answer your question:
There really are no forms in asp.net MVC. There are views, which show your order, and there are controllers/actions which allow you to run code to generate views, update your database, etc. You ask if you need another form - the answer is No. You will, however, need at least a new action on a controller, and possibly a new view to confirm that the order was changed. An overview to a very simplified solution would be:
You want to allow an order to be marked as closed by clicking a button. Assume you have a controller called Order, and a view (in the order views folder) called Details. You'll have to add an action which takes an integer as a parameter to your order controller called "Close". In that action, you'll read the integer parameter (the order ID) and execute code to update that particular order to closed. You'll probably want to return the same view with the udpated status from this action. You'll have to add a link (probably using HTML.ActionLink function) to your view to call this new action.
In MVC everything is Post and Get actions. You can post to difference controllers. It seems you need to spent a bit more time reading about it. If you do not fancy reading - try some nice video tutorials for beginners. http://www.asp.net/mvc
I'm building a site in ASP.NET MVC 2 that will allow for anonymous users and registered users. When a user is logged in, I want to display multiple pieces of information related to that profile on every page (i.e. hometown, favorite color, etc.). From a view perspective, I understand using Master pages and creating partials to keep it DRY.
However, where I am getting stuck is how do I pass this user information to the view for every page? I already have the relationships between database tables established (I'm using EF), so I can do this on an individual basis for each action through ViewData, but that's obviously ridiculous for every page on the site.
So far, my research has started to lead me down the path of creating a base controller and base view model that the other controllers and view models will inherit from. But I feel like I'm missing something obvious. Any pointers?
If you have your Master page use the RenderAction method, it can invoke controller actions for the various repetitive parts of your page, each of which can perform data access and render a partial view. That allows you to separate your view models while still displaying certain elements on all your pages.
This approach works great for us.
We use a base controller to store it in ViewData.
You could also use an action attribute on the controller rather than inheriting from a base controller.
You could create a base class for your models that contains the data that is display on every page.
I am kinda of confused on when I should be making a new controller it seems like every time I make a button that goes somewhere I would need to make a new controller to get the right pathing names.
For instance in this scenario I have a signIn controller.
this controller would have
1. Login view
2. RestPassword view
3. CreateAccount view
So if they click login they go to some other controller(lets call it AccountController) so this will have all the account view and stuff in it.
Now how about the RestPassword view? When it rests the user password I want it to go to a page that shows them that it was a success(most sites seem to do this for example asp.net site if you enter in a email address it will go to another page and tell you that the new password has been sent).
So now what should it be another view? a controller?
If it is a view then the pathing would look like
http://www.site.com/signIn/EmailForgottenPassword
what kind of looks weird to me.
If I make a new controller then I could have
http://www.site.com/EmailForgottenPassword
What looks alot better to me but this controller would have one just one view in it.
Another example would be on this sigIn page their is a Create Account button. Now when clicked this goes to another page that has a list of different accounts.
Should this also be a new controller? When the accounts are listed on this new page they all link to a Registration Controller with many views in it.
so it would be like SignController -> RegistrationController -> RegistrationController.
this would probably get some nice links.
So like I said it seems like to get nice links that make sense you need to constantly make new controller after controller.
So I must be missing something.
The truth is you never actually need more than one controller. Separate controllers are just ways of separating your concerns. In other words, OO design paradigms impel us to logically divide our code into modules, but you don't have to - everything can be in one controller.
What you do need is a separate controller action for each different type of request you want to process. That is, you need a controller method exposed to the routing table that can be called by typing in some URL and/or providing some GET or POST data. This method then decides what to show the user (the view).
Also, you can have any URL you want point to any controller or controller action you want by modifying the routing table in Globals.asax.
You probably have more specific questions about my answer - please post them and I will edit them in.
In your specific case you one controller would suffice. I would name it the AccountController and add the following actions to it.
Login
Logout
Create
CreateConfirmation
ResetPassword
ResetPasswordConfirmation
then for the ones you want to have confirmation screens you can use the the Post Redirect Get (PRG) pattern.
as to the naming. In general you want to use noun for a controller and verbs for actions on those controllers. That way you get nice readable URL's that make sense. And for the noun you can pick the logical/business term (better then the technical term) that the controller deals with. So accounts, customers, products, blogpost etc...
If you are following SOLID principles then you should name them very specifically. If you are using ASP.NET MVC 2 then I would put major widgets into "areas" and then give controllers good names. Make your URLs happy!