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.
Related
I been practicing developing an application in .NET and with other languages and server, and now I want to start sketching out an architecture I want to implement.
The reason why I want to separate the two is because I cannot focus on a specific thing when everything is Jumbled into one server. I would like to be able to have the freedom to offer features that would otherwise bottleneck one server and not another(ex. notification, chatting)
What brought me here to ask this question is because I am totally confused on why everything on the UI is always called MVC. When searching for solutions to a distributed architecture that I can implement I keep running across frameworks that use an MVC pattern.
How does this actually work when you already have your API models? Isn't an MVC pattern just going to duplicate all of the models on the API (ex django, asp.net mvc or ruby on the rails)?
One scenario that threw me off and brought me to research a whole lot more, is when I wanted to create a registration form that has steps, validating the username uniqueness was on one step and zip code was on another. I found myself wanting the tweak the API based on how I wanted to present my view and thought about having to do that for different types of clients(mobile, different user agents) and quickly backed off that idea. The problem is those fields need some sort of call to the back end and every view wont have that way of registering.
The main question is how do I implement a UI layer that I can customize toward certain views, without changing the way my API is structured?
You might be interested in this article from LinkedIn dev team.
https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
I'm building a new Rails app for a client and one of the requirements is to allow people to fill out service request forms. There are 10 request forms so far and they're all different. To implement this I was thinking of creating a separate Model, View and Controller for each one to keep everything simplistic and RESTful. I'm kind of worried though about having 10+ different MVCs and routes just for the forms. Is there potentially and better way to achieve this?
Also the data submitted just gets emailed. No saving to a database.
Thanks for any help! :)
You're correct to make them all separate resources, controllers, models, etc.
If possible, you can DRY the code that is similar among them. For example, if some of the forms have similar validations, or parameter filtering, or scopes, etc.
I'm kind of worried though about having 10+ different MVCs and routes just for the forms
In my opinion, 10+ different MVCs are fine for 10+ different resources. You may be interested to read about "DAMP" coding. I personally recommend DRY underpinnings and DAMP resources.
(My apologies for all those that voted the question down. I'm not trying to avoid researching. I've been actually trying to find a way for doing this for the past several hours. The only thing I'm trying to avoid is paying the Umbraco TV membership fee)
This is probably a dumb question:
I'm somewhat familiar with MVC, but really new to UMBRACO 7. I'm going through documentation on how to add restricted pages (pages accesible to some membership types) and I have to create a model. I've been searching through the whole UMBRACO settings and developer back office pages but couldn't find where to add the models. Neither was I able to find in VS where to add them (which would be even more convenient).
Can someone point me in the right direction or any documentation where I would be able to understand how Umbraco and MVC+VS work together and add models and custom code to an UMBRACO 7 website?
(I have the site running locally in VS2013 and DB in MSSQL Server 2014)
THANK YOU KINDLY!
I would recommend you read up on Umbraco surface controllers. You can learn a bit about what it is and how it works here: http://our.umbraco.org/documentation/Reference/Mvc/surface-controllers
To answer your question, you put your models where you always put model classes in MVC: Pretty much where ever you like in the solution. However, it would be pretty good idea to put it in a folder & namespace called Models.
When I want to restrict access to pages in my umbraco site, I usually find that I can use the default "Public Access" that umbraco has set up. Just right click on a node in the content tree, and you should be able to restrict access to either specific members or a specific member groups.
https://our.umbraco.org/wiki/reference/umbraco-client/context-menus/public-access
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 :-).
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. :)