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. :)
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!
I am a little ashamed for asking so many questions, but I really want to learn.
In Sipke's blog a webshop is created. There is one specific question that boggles my mind when trying to do something similar.
Let me spell out the basic requirements:
User registration form and login, etc. This one is covered by the blog and it works nice.
Creating product parts and so on. This one is covered and no problem there.
Ordering by filling in an order form and making the payment. See down
Having the order page maintainable by customer. See down.
Viewing your own orders and their status. See down
Maintaining customers and orders from backend system. This one is covered by the blog and I need to do some work there yet.
As for items regarding creating orders and viewing your orders. I have followed the approach for creating records and using standard MVC controllers. But then I encountered problems:
Menu for orders page. This I had to do manually after installing the module.
The order page itself. I had to create the view including title and so on. But I can imagine a customer wanting the order page on another menu and with a different title. And maybe add even some own content to the ordering page. This I couldn't achieve by using standard MVC approach. So maybe I am using the wrong approach here. So I was thinking about using contentparts for creating an order and displaying them and using the drivers and handlers for that. But before I go down that road and refactor everything I want to know if that is the right approach. A downside could be that once the module follows that route it can then not so easily be reused with customers that have other cms's capable of hosting an MVC3 module.
So when to use drivers, handlers and contentparts and when to use standard controllers and views.
You should use Drivers and Parts (with Handlers if needed) when you want to create functionality for content items. E.g. if you want to display a custom media with all products, you could create a Part (together with its Driver, etc.) to handle that. Read the docs on Parts.
If the functionality is not tied to content items the most possibly you want to use the standard MVC toolbox, it's fine. Look at the built-in modules how they do that. E.g. the Blog module uses controllers and views to show the admin UI, but has parts to enhance the functionality of for example the Blog content type.
To make things more complicated you can employ ad-hoc content items to build a page that you'd normally do with simple views, but that's an advanced topic :-).
I'm building a website using MVC3, EF, and Razor and I currently have the front-end of the site mostly working. It's a "store" of sorts with products, users, etc and in the front end you can browse for products, see ratings by users, and purchase the products.
Now, I am thinking about the back-end and from what I have so far, it seems like hte back-end will be redundant in a lot of ways. I would like to have an entire back-end area to manage all the products, users, sales, etc (preferably /Admin/Controller/Action, but if I want a page in the back-end that lists all of the products, this is going to be identical (at least from the controller standpoint) to the front-end controller that lists all of the products.
My question is, what are some good ways to go about this, am i completely wrong so far, or am I on the right track and just need some tweaking. I have also read about Areas, but have been unable to find any good documentation to use with MVC3. Should i duplicate functionality in the back end or is there a better way? Thanks for the help!
I believe you're going about this in a good way, but I think you're dead on when you were thinking about putting your Admin in an Area. I tried googling for something from Scott Gu for areas, but surprisingly couldn't find anything dedicated to it, but there is this MSDN article:
Organizing an Application using Areas
I know you're worried about having controllers with similar actions (and maybe similar models) with the admin as well as the frontend, but it's still probably optimal to separate the logic. Don't over-think or over-architect it, because at some point, you may have to modify the admin controller, but not the front-end controller. Models are typically the point that can be commonized between controllers.
I have a web application I want to build, how should I manage all my tasks with fogbugz.
If I want to list all the tasks I have on a page by page basis, should I use areas for that?
I also want to break it down to modules, again I use areas?
example:
Users
add user
delete user
assign permissions/roles to a user
or if it do in on a page basis the list would look different.
Over time I've found that it's a waste of effort trying to rigidly structure your cases by anything other than Project and responsibility (Area).
Just get the cases into FogBugz under the right project and area with a good title.
So, the Project is whatever the product or business project is that you're working on.
The areas should be things like UI, Code, Docs, Data Migration, the kinds of things that people have different responsibilities and/or abilities in.
Then title your cases for easy management and searching, keeping the scope of the case to a few hours if possible, certainly no more than a couple of days.
So, from your example it could be as simple as...
Add Role
View Role
Update Role
Delete Role?
List Roles
Add User
View User
Update User
Delete User
List Users
Add dependency checks to delete role.
To be honest, even the above is probably a little over-board, you'd probably get away with:
User Role add/view/update/delete/list
User add/view/update/delete/list
The simpler you make it, and more trust you put in your devs, the less hampered your devs will feel and more likely to just get on with it.
Users can filter by cases assigned to them, so they can always view their own queue.
Lots of different areas will just create unneeded complexity - you just don't need that level of breakdown.
Bear in mind that you should never have large numbers of active cases, and you don't need lots of categorisation for short lists.
I find that the best use of the area flag is to group work into a queue across more than one developer. Then you get a queue anyone can quickly view.
For instance you might have a "Product planning" area for feature ideas that you haven't decided to do yet. In a large team you might assign an area for each sub-team, so each line manager could view their queue on its own.
We have one large and complex project that's been using Fogbugz for 4 years and we've never needed more than 5 areas. If we'd split areas the way that you suggest here we would now have hundreds of them.
I was just going through the "AccountController.cs" code (the default one which appears when you create a new ASP.NET MVC project). When I tried to compare it to the one that is proposed in my book, I noticed that the two controllers share the same concepts and implements the same methods (LogOn, LogOff, CreateUser, DeleteUser, ChangePassword, etc.).
Now, I'm wondering why someone would want to create an AccountController of his own to replace the default one.
Almost, all the books (even professional ones) do not suggest we should create an AccountController. But, one of them (The Beer House) spend a whole chapter on how to implements just that. I really liked it as was able to see a real professional project's code. But, if it's a stuff for very big big website, I might be better off spending my learning time in other subjects.
My question is this one: For a professional website (not very big big), is it safe to use the default AccountController? Or I need absolutely to create a new one. And (most importantly) why? What are the limitations of the default controller??? Can I provide some enhancement to the default one in case it's just a matter of making it specific to address a need?
Thank you
Usually you will need to rewrite or at least make many changes in the default AccountController. For example:
Default AccountController allows anybody to register (create new account) without any email confirmation or even CAPTCHA.
Default registration needs only login, email and password. Usually you would like to adjust user profile data to specific application.
There is no "forgot my password" option
There is no "Edit profile" option.
I don't know if it is a good idea to integrate your database schema with autogenerated tables (aspnet_XXX). If you have your own "Users" table in your database schema maybe it is better to write your own MembershipProvider using your own "Users" table.
Default profile provider stores profile data in not intuitive way (there is no table with one column per profile field).
That's a tough question to answer. You need to enumerate any specific needs, requirements, or general funkiness and compare them to what you already have completed for you. If you wire up the existing and it suits you just fine, there's probably no reason to write something new.