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!
Related
I have a question about how to design my controllers properly.
Project is fairly simple: blog, immage gallery with categories and images inside them, news secion.
However I don't know how to organize my controllers for this because I want to make somewhat admin panel where administrators can edit, add and modify these things. I've came up with 3 scenariosu so far...
Admin panel will have links to site/controller/edit, but layout for these action results will be different from standard one.
Admin controller will have all these actions like BlogAdd, BlogEdit so that url will be something like /site/admin/blogedit.
Create copies of Blog controller in admin folder so url will be like /site/admin/blog/edit - i sense problems with routing since 2 controllers with same name does not sound like a good idea, however I like ho URL looks in this situation.
What I'm trying to make is CMS somewhat similar to wordpress, where blog creation,editing and deletion is completely separated from default blog itself.
I suggest you stop thinking about URLs and Controllers being a 1->1 relationship. This will make things MUCH easier and less confusing. You can make the URLs work however you want with MVC's routing mechanism and there's no reason to restrict your controller design/organization because of the URLs you want, because you can always adapt the routing to with with the URLs you have in mind.
While building the website, just focus on the controllers (and the general interface) and ignore the URLs until you get to that point, and then when you come up with a good URL scheme go into the routing system and add the routes to connect to your existing controller actions as you want.
Once you code out your blogging engine you will have a much better idea of the user workflow and will probably find different ways to organize your URLs, and you can then reorganize your URLs without touching the controllers themselves.
As to your first requirement:
There are two ways to do this depending on your end goal. If your goal is to display the same core content, but have different user options available (different overall layout, additional buttons on the page, etc..) then the best idea is really to just pass in an IsAdministrator property in your view model, and make the slight changes to the page based on if that's true or false. The reason is because you still (most likely) want the core of the page to be the same, and this keeps you from duplicating code that is related to the core data (data that's being displayed for both admins and non-admins).
Edit: So in summary, organize your controllers based on what makes it easier to develop with, not based on how the user interacts with the system with. You can always change the latter, changing the former is harder and will make maintenance annoying.
You can create Areas in your MVC project and have your admin functionality in a controller in your admin area.
This will allow you to easily seperate your administration functionality from your general blog functionality.
That's how I'd do it.
Why don't you keep the routes the same and handle the different roles via security? For example:
/blog/name-of-topic/view to view a topic (all users)
/blog/name-of-topic/edit to edit a topic (only enabled for logged in users)
/blog/add to create new topics (only enabled for logged in users)
You can handle these actions in a single controller and decorate the actions that require logged users via the [Authorize] attribute. Same thing with the links on your views, you would enable the links to edit and add topics only to visible users.
You could still have a separate panel to allow admins to hit the aforementioned add/edit links .
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
So I am new to programming and working in C# and learning MVC. I have finally undertaken my first personal project to put to practice what I have been learning from the books/tutorials I have been following. My project is your typical store that list products, has a shopping cart, user account, admin site...etc.
I have managed to wire up NHibernate to my MySQL DB, and posting records to a view.
My question is "where should I start?". It seems I could go a lot of different directions, Admin site to manage the site and products, getting the products showing on the site as I would like, User accounts. What is some advice of how I "should" tackle each component?
I leaning towards the admin site since logically putting products in the store comes before showing the products on your store.
Any advice is greatly appreciated.
I concur with #Tod
Pick a portion of the website that is needed and build it. Build up your model (include a viewmodel), then your controller, and finally your view.
In my case, I chose to start with Users.
I created my Database and Users Table (no I didn't use code first or EF)
Then I created the LINQ DBML file
Then I created as super simple repository that talks to the LINQ classes
Next I created a service layer that does a little more heavy lifting before communicating with the repository layer
Following that, I build a ViewModel that would "transform" data that was to be used in the view. This also included building some HtmlHelpers and Extension Methods.
Now to my controller. I build new ViewModel object, pass an object to the ViewModel, and then return the viewmodel to the view.
Lastly I implemented the View, did my CSS and Markup.
So when I visit the site, I don't see a whole lot except for a nice finished Users section. This also includes a sign-up area, login area, etc.
Now that the Users section is finished, my next big section is "Events" whereby I will start the process all over again.
Start with what you can use first. If you can't put products in the system, what good is "getting the products showing on the site as I would like". On the other hand, having a site where you can enter products may be (somewhat) useful on it's own.
Even though you are the client, ask yourself: what is the smallest piece of functionality you could build that would be useful for your client? Build that first!
Good luck! Enjoy programming!
I guess its a bit of a personal preference. For me, I'd rather work on the front end customer facing stuff first, ie: rending products, shopping cart, purchasing and checkout.
The admin side of things doesn't really add value to the product from a customer perspective. In a less than ideal situation you could release your store without an admin interface, and manage products directly in the database (not ideal), but you could still release it and sell products to the public.
The admin side doesn't add that kind of value, and even if you can add and remove products from the system, you still can't release the product as customers can't see or buy them.
I like to focus on what adds the most value first and build from there - in practice however this isn't always possible.
Either way though, I think taking it from which ever direction you're more comfortable with is the best approach. If logically you find it easier to conceptualize the process of ordering products when they've already been added to the system from an Admin panel, start at the admin panel.
If you find it easier to build an edit product page based on what you've determined you need to render on the public facing page, then start with product listing and build management around it.
The user account stuff is used throughout your site so you should create that first. The shopping cart is going to be associated with the user account.
Ok going by your question, in my opinion, you might want to find yourself a specific goal, like doing a website for someone that owns a business that you know (this is what I've done, and so have a couple friends of mine).
I've found that the more specific the aim, the better the coding experience. So if you're motivated to a particular project then you'll know what's necessary to do. Give yourself a project to do like a music library utility for example, and see where it takes you. :)
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.
I'm creating a new ASP.NET MVC application. So far I've used the Account controller for actions related to a user's account -- Login/Logout, Activation (like Register, but I use Register for other actions in the site so I've renamed it), Add/Update Contact information. Up to now, though, I've been concentrating on the administrative user views.
I'm at the point where I'm going to start creating the various views that non-administrative users will see. These are rather limited compared to the administrative interface. My inclination is to create a new set of views and associated controller in the User "family" instead of using the Account views/controller. Is this a good idea or should I stick with the Account controller? My feeling is that since this is for ordinary users it should be a separate controller since Account would apply to both ordinary and administrative users.
EDIT: After reading the first couple of responses, my refactored question is:
Do you consider the Account controller to be for administrative actions related to the user's account or for all actions on the user's account? Would you distinguish between membership/role related views/data and application related views/data to the extent of creating a new controller.
Related, but doesn't directly answer my question: ASP.NET MVC Account Controller usage guidelines?
I don't think there's a right or wrong answer here, so I'll give you my opinion.
Technically, either solution (extending the Account controller or creating a new controller) will work just fine.
So I think this is more a question of how the users perceive the functionality. I think it's a good idea to follow the convention that the URI dictates the controller (or vice versa, if you prefer).
If, for example, you'd like to have the "administrative" actions on a separate path, then that should be a separate controller. You might want to do this, for example, if you use an IIS module for authentication or if it makes your log analysis easier.
On the other hand, it might be the case that the users perceive account functions and administrative functions as part of the same family of actions, except that some users have additional features. If so, then that suggests that should be on the same path in the URI and, hence, part of the same controller.
Summing up, I think this is a question you should ask your user representative instead of folks on this site. :)
Update: Regarding your updated question, I would say that it is fairly natural to put an action for changing a user's password on the Account controller, and that action could be invoked by the user herself, not just an administrator. So I wouldn't presume that the Account controller is strictly for administrative tasks. On the other hand, your example of the fund-raising performance is well outside of the scope of membership-related things, so it is not clear that it belongs on Account, either. I'm still leaning towards, "ask your user representative."
In ASP.NET MVC you will usually create controls based on data types rather than access types. For example:
Instead of 2 /Controllers/UsersControl.cs and /Controllers/Admin/UsersControls.cs it is easier to use one common controller for both admins and regular users - /Controllers/UsersController.cs (by setting different [Authorize] attributes and views).
I would keep existing AccountController.cs for encapsulating account related functionality. And just add new UsersController.cs for the rest Users related functionality (which could have methods like OnlineUsers etc.)