I am trying to build a new MVC Project. The thought is I will have a parent domain, and I will be hosting multiple sub products at different sub domains.
[ For Users it will be totally different products.. like: life.insurance.com and general.insurance.com].. and it is also possible that two different teams work on these two child products and they may have different Release Date.
Main thing is, I want to change my Web Project Layer. The Domain Layer, DAL Layer, etc will be common. I was searching for some best Industry Practices in MVC.
Thoughts that I have in Mind:
Create different MVC Areas in Web Project. But what if I want to send product A code to Production but not the Product 2 Code. [How to Resolve this]
Use different Web Projects and change the dll only at Production.
Please suggest. or any New way to handle this scenario?
Under Main Project solution, Create Separate MVC projects for each of the subdomains.
You can create multiple projects for DAL, DomainLayer, Crosscutting, DTOs, UI, Test etc. You can extend it as much as you need and you can find many sample architectures in different complexities. Considering your specific questions, you can route requests using Area as you pointed. In addition, you can implement Areas in different projects which enable you extend your solution without modifying the web project. However; you need to take into consideration that once you add DLL references to your web project, you cannot directly change specific DLLs without rebuilding the whole web project. In order to achive that, you need to resolve your plugin assemblies in runtime. So, you can use Assembly.Load that will help you load specific DLLs anytime you wish.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I'm developing an app and I am pondering over something. So I figured I would ask here for people with experience to tell me what they think about it.
So I have this controller (Store controller) which is huge and has a lots of methods, Get and Post actions, and so on in it. It works fine, but I'm still in development stage.
I am wondering what would be the best practice: to have this controller which holds so many methods and actions, or splitting the methods to many controllers? Is it ideal to have one controller deal with almost all of the methods, or many controllers?
And before you ask, yes, everything in my store controller is "store related". But in my store I have items, packages, and so on.
Edit
Thanks everyone! Following your advice, I have broken my huge Store controller into smaller controllers: one for the Items, one for the Packs, and so on. This indeed made the code more readable. Also, a lot of comments provided will put me on track for upgrade, so thanks a lot!
It is definitely better to divide all your controller's actions into some logical packages - so to move them to separate controllers. Thanks to this it all becomes much more readable and intuitive for you also for other developers who will work on the project.
The question is: how to divide it?
There are in fact a few criterias that can influence such a decision for e.g.:
A controller should be connected with a certain set of logically connected pages. So for e.g. in case of an e-commerce platform you would probably have a CheckoutController, ProductController, UserAccountController etc.
You should also take into account which business concepts should be taken into account. In your case you have a concept Store, but as you are probably aware of this that it is a very broad concept in itself. So instead you should probably distinguish some more details in the business concepts.
A quite common approach is to divide controllers by CRUDs, although it is not always applicable.
On the other hand your controllers should not be too granulated - so you should not exaggerate with it.
Please remember that ASP.NET MVC uses CoC (Convention over Configuration) approach which is also applicable to controllers and views naming conventions and the way they are grouped and placed in appropriate directories. When dividing your controller you should take this into account.
You should have a controller per discrete unit you're working with. So, if your controller manages multiple entities, then yes, I'd say it's time to break it out. However, length of the controller, otherwise, makes no difference.
Now, the only problem you'll have using separate controllers is your routes, but that can be easily fixed by either of the following:
Use Areas. Areas allow you to sort of create a sub-MVC project. It'll give you Controller, Model, and View directories all under a new prefix. So, if you had a controller named ItemsController in your Store Area, the default route would end up being Store/Items. However, C# developers have very mixed feelings regarding Areas: some love them, some hate them with a burning passion.
Use Attribute Routing. MVC 5 has a new feature called attribute routing. This allows you to specify the route directly on your controller and its actions instead of relying on the default route or adding tons of custom routes to your route config. So, you could then easily have as many controllers as you want and specify that they should all be prefixed with "store" in the URL. As long as there's no conflict in the rest of the URL, you'll be fine. If you aren't working with an MVC 5 project and don't want to upgrade, there's also a Nuget package called AttributeRouting that offers these features (and actually more). For what it's worth, the author of that package is also the author of attribute routing in MVC 5.
I prefer multiple controllers than a single controller with many actions. I would do it this way - Let a BaseStoreController derive from Controller, this controller is going to have the common functionality and properties. Then have StorePackageController, StoreItemsController etc be derived from BaseStoreController.
And inside each controller I will have corresponding Actions related to packages, items etc. Inside each action I will make sure I will use Command Pattern and Facade pattern to ensure proper code separation.
The standard way I approach it is to have one controller per menu option
For example, say you have a site with the menu options
Home, Products, Blog, FAQ etc
I would have a HomeController, ProductContsController, BlogController and FAQController
You could also potentially create one or two generic controllers that handle shared actions used by several sections of your website and a base controller than handles generic tasks such as tracking and logging page visits.
One other thing to be aware of is SSL, especially if you decide to do some shared controllers actions or decorate an entire controller (For example shoppingcart etc) with SSL
If your methods are truly "Store" related and bind your model to the View, then that's one thing. But if some of your "Store" methods are essentially helper classes, that is, methods that don't directly interact with your view but do serve a purpose when working with your Store model, then create a separate "Store" helper class and place this in, for example, a "HelperClasses" folder in your root. In my opinion, and I'm sure opinions of others, you want to try to only keep methods in your controller that directly tie into the model (the Store model) that your View renders and works with. This encourages "separation of concerns". If your Store methods don't do that, send them to a helper class. Basically - your controller acts as the middle man when rendering your model to the view. It helps control the process, so every method in your Store controller should really have something to do with how your controller sends your model to the View. Hope that makes sense.
And as Chris Pratt mentioned, if your controller manages multiple objects, then yes separate them into separate controllers, OR, create a ViewModel to handle the multiple objects, but from what you said, I don't think this is the case because you mentioned everything in your Store controller is "Store" related.
you might consider using a partial controller and split methods by logical meanings.
public partial class StoreController: Controller
{
public ActionResult Index()
{
return View();
}
}
in in some other .cs or .vb file:
public partial class StoreController
{
public ActionResult Show()
{
return View();
}
}
take a look at: http://msdn.microsoft.com/en-us/library/wa80x488.aspx
I'm not sure if this is the right place for my question, but i will give it a try.
We are starting the development of a new product wich will use asp.net mvc 3 razor as the presentation layer. The application has about 7-8 different roles and all the roles have different views on wich the data will be displayed.
I've build a nice framework with the help of NHibernate and the implementation of a couple design patterns, so this side of the applicatie will be easy to adjust and apply maintenance to.
I want the presentation layer to be as adaptive as my framework and that's why i'm trying to figure out a way to have as less views as possible for all the different kind of roles but with full functionality. What kind of implementation do you use for distributing views to the end-user based on his role?
I thought about using jquery templates, but with the current possibility of views and the razor syntax it sound a bit unnecessary and not the preffered way to go.
Any information that i should keep in mind while developing this application will be nice, think about, common mistakes, best practises and suggestions etc.
Looking forward to your replies.
One way to reduce the number of views would be to use IsInRole() (or an equivalent if you have something custom) in combination with partial views. In the most simple case, you could have one view that also renders partial views within it based on specific roles. Something along the lines of:
#if (HttpContext.Current.User.IsInRole("admin")) {
#Html.Partial("_StuffForAdmins")
}
Depending of your situation, some partial views could then be shared across multiple different roles, reducing duplicate code. User interface elements that are publicly accessible by all roles could just be placed on the view itself without role checking.
EDIT: An alternative syntax is:
<div>
#if (Context.User.IsInRole("admin"))
{
#Html.Partial("_StuffForAdmins")
}
</div>
I have an interesting situation where I need to quickly provide a feature to a customer prior to our normal build schedule and outside of our normal build repository. I need it to go live tonight, without a recompile.
Our site is deployed with everything compiled into a DLL, besides the Views. This means that at anytime I can edit the Views on the fly in the middle of the day. Is there a way I can add a new page that can be invoked via HTTP GET or POST so that I can do some things I would normally do in a Controller without actually making a new Action, etc? I know this is not a good methodology and it won't be the long term solution, I just need a plan... business is business after all.
Edit: I also cannot edit the Global.asax routing table, it is also compiled.
The first thing you'd have to do is pull out your Routes into XML files so you could add routes on the fly (all it'd do is recycle the App-Pool). I also recommend pulling the Routes out of the web.config into their own .config file, that's referenced in the web.config.
The second thing is you would have to mix Webforms with ASP.NET MVC if you wanted to do this.
It's important to note that using UrlParameter.Optional is problematic with XML based routing, at least I never got it to work.
I believe because of the way routing works in MVC it will try to find a valid path using the Routing system first. Failing that it should look for the aspx page using the normal method of just looking for the file. Keep in mind that aspx files (or razor files) that are just asp.net pages should not be in the Views folder, as MVC apps are configured to refuse serving up files in that directory. I'm assuming your're just talking about a single page or two? Anything more complex than that and I would look at trying to separate them more strongly as in the article mentioned above.
You could mix classic webforms with MVC.
I'm almost positive you could add a new Controller class to the App_Code folder and it would get picked up without a compile needed.
I guess it all depends if you have a convention based route that will hit it or not.
I have to setup an MVC project to house all the HTML documents. This would be like a hierarchical structure using routing. The pages don’t have to function, just act as placeholders. It’s really just for the group to see all the HTML Pages to get an Idea of functionality. Then we would back fill groups of pages with the functionality by creating the controllers, model etc. How would this be best accomplished? Are there mock frameworks that could accomplish this? So it would be a project just having views, with a control ler that allows navigation between pages, simple to show mostly static HTML pages. The idea is simply for the group to see all the functionality, and to put together a structure to start coding. If possible we would like to see the correct URL based on the route table. What would be a quick solution for this while we work on the back end Object/Domain model?
This is a rather crude but simple solution. Just add the Server.Transfer line to your controller to inject the link to the physical file (I'm assuming the HTML documents exist already):
public ActionResult About()
{
//TODO: remove mock up redirect
Server.Transfer("~/MockUps/AboutUsMockUp.htm");
return View();
}
If you already have the HTML I would just go ahead and implement the views whilst you create the controllers? It may seem like a little extra work up front but by the time you work back through the above suggestion to re-implement the proper views at a later stage that could equate to more time spent!?