We have an ASP.NET MVC website with two main models /Account and /Store. Account model is dedicated to user registration, password recovery, profile update, etc. while the Store one is dedicated to shopping cart and checkout management.
During the purchase process, we want to give the user the ability to login (and eventually recover password), update his/her profile data, etc. This involves accessing the data of the /Account model and the need to return to the original purchase process page.
What is the best way to accomplish this (jump elsewhere and return) with MVC?
Thanks,
Alberto
Alberto,
If these classes are really models then you have no problem to use them in any controller.
The best way is to use partial views and just invoke them from your controller.
I hope this helps you, let me know if you require more clarification.
Alexander
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 have been doing some research about how to do custom profileprovider in .NET MVC.
It seems pretty complicated. Is there any other alternative?
And this is my major concern, why do ppl bother using customer profileprovider? If they want extra information about a user, why don't they just make another table with OneToOne relationship with aspnet_Users with userId or userName as the foreign key?
Please clarify. I'm trying to implement user profile functionality, but I don't wanna go down the wrong path.
Thanks
DG
(not to sure if this helps talk about custom profile providers.. unless I'm misunderstood...)
IMO, what ever you do .. avoid (the baked in) ASP.NET Membership at any cost! It's sooooo over engineered, you'll want to stab yourself in the eye with a blunt spoon :(
Trust me. avoid it.
Why: Should I use the built-in membership provider for an ASP .NET MVC application?
So .. what can we do instead?
It's just so simple to roll your own Username/Password and leverage the built in Forms Authentication. For myself, I'm not a fan of storing -any- passwords in my own database .. so i prefer to use Facebook, Twitter or OAuth as my mechanism for authentication .. which then means I finish up with a simple, basic, custom user class.
I also create my own custom IPrincipal and IIdentity because I want to store a bit more info in the cookie, which Forms Auth creates when a person has been authenticated. This then helps keep my code in my Controllers cleaner and way simpler.
For example, I store the userId of the authenticated person in an encrypted cookie. (the default option is to only store a Name). I also store one or two more things .. but you get the idea. This way, I don't always have the hit the DB to retrieve any user data OR store this crap in a session.
With a roll your own, u can create extra meta data (birthday? mum's maiden name? social security number (joke) ) .. and have that extra profile data. Same table? extra table? who cares ... that's a decision to make way later (and EASY to solve). Get your model right, IMO :) Then once u've locked down your model, you now know what's required and what's optional .. and u can make some DB decisions then.
TLDR??
Avoid the built in ASP.NET Membership crap
Roll your own .. and keep it simple.
If you're feeling advanced, also roll your own IPrincipal and IIdentidy to really rock your world.
GL HF and don't stab yourself with a blunt spoon, in your eye!
I am creating an Asp.net MVC application and I'm currently using the built in Authentication/Authorization code that comes with the sample MVC app. For the most part this is working ok and I kinda understand what's going on.
What's concerning me though, is that now I kind of have my users stored in two different tables across two databases. i.e. I have users in my App's database that represent the "Customer" entity in the application, as well as the "User" in the Authentication database that's used to log in someone to the app.
Should I take the logged in user's User.Identity.Name value and do look up in my Customers table or should I merge them into one table? What's the best practice way of handling this?
Please forgive my ignorance - this is the first time I'm working with a system like this.
Any feedback is greatly appreciated!
It's helpful to think of credentials and the records that associate a person to application data as two very different things. Depending on the application, your Customer may not have credentials to log in or you may have an administrative User that logs in but isn't related to your application data.
Separate credentials are also useful if Users access more than one application with different rights for each.
For these reasons, I'd keep Customer and User separate and look one up from the other where appropriate.
You can extend the .Net Membership Provider to take all the information you want and post back in a single model I think.
See this one ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?
And this one How to implement ASP.NET membership provider in my domain model
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.)
Just getting started using MVC in ASP.NET, I'm going to have it so users must login to use certain features. Now I have a User controller that stores users in a table and another controller that adds data to another table. Once the user is logged in, how would I get their id from the user table from within the add controller in order to add their id to that table?
I think that to solve your problem from the top down you might want to look into ASP.NET MVC Authentication instead of implementing something like this yourself. That said if you have a great reason for continuing down the path you're taking then I have some suggestions.
Firstly you may wish to consider using the repository pattern to add/remove/get data to and from your database. Any controller can implement any repository it likes so your add controller can just implement the user repository to get the user.
Also, remember that in ASP.NET MVC you can use session variables. If you need to know which user is doing what, then just store it in the session and retrieve it from there.