Could some one please explain the advantages and disadvantages of using the new MVC2 Areas feature?
I don't understand what is so great about them. If I am adding an admin area to my MVC application why not create a new Admin folder in the main Views and Controllers folder? What does creating an area really get me?
This is what Phil Haack says:
The scenario that areas address is
being able to partition your
application into discrete areas of
functionality. It helps make managing
a large application more manageable
and allows for creating distinct
applets that you can drop into an
application.
An admin section wouldn't qualify as an applet as it logically belongs with your application and may even share models with it.
Related
Currently, our single-project Episerver solution serves up a single website and has been working great. Soon we'll be developing an additional, separate Episerver site that will need to live within the same solution but I would love for the two codebases to remain separate while still sharing the same Episerver DB. For the site that currently exists, we have a lot of page/block models, so I expect any refactoring will be no light lift.
Is there any documentation/guidance, aside from this, that details out best practices on how to separate out the models, controllers, views, etc for each site into their own project?
Is this better achieved through the use of Areas instead of separate projects? Some other approach I'm not considering?
Any help and/or discussion around this is greatly appreciated.
I have a solution which contains 2 MVC Website Applications (Website & Website Admin System). As I am progressing with the build there is a lot of common code especially in my View Models, HtmlHelpers etc. Is it good practice in MVC to treat these two sites as separate entities and keep code in one site specific to that site and manually copy code across to second site? Or is there a practice to share this common code across web apps?
It is just natural for me to refactor common code when I see it? However I am not so sure how this works within an MVC environment. Any suggestions or comments welcome.
You can create a class library project and push that code to that project. Then have both website projects reference that DLL. I believe views are about the only thing in MVC that you can't do that with. I believe you can do it with controllers too, but I haven't tried it.
If your sites are sharing many ViewModels and HtmlHelpers I'd take a step back and examine why they are two separate sites. Is the second one an Admin area of the first site, or is it a completely separate entity altogether? If the first, I'd probably have everything in one site. If the second, I'd do as Brian Ball suggested and create a library project that the two sites share.
I'm designing a Module that is to be consumed by two distinct WebSites. Everything will be written in MVC (the module and both web applications).
I would like to design my module so that the code can be included from a shared location. I only want to maintain a single version. My first thought was the Area feature of MVC 2. But from my reading it appears as though MVC 2 only "officially" supports Inline Areas.
It sounds like MultiProject support for Areas could be dropped in the near future. What are the pros and cons of Areas implemented as single projects vs multiple projects in asp.net mvc
Are there any alternatives?
A real world example of my design would be creating an MVC Shopping Cart (this would be the shared Module) and consuming it on two different MVC web sites (say a Book Store and a Bicycle Parts Store).
MVC Contrib's Portable Areas are just what you need:
http://www.lostechies.com/blogs/hex/archive/2009/11/01/asp-net-mvc-portable-areas-via-mvccontrib.aspx
My experience has been nothing but positive. Have 3 apps sharing 3 portable areas. One is going into production pretty soon.
You can still make it an Area, maintain it in one place and copy it to other projects when needed. There's no way I know to make it work out of the box without setting up the appropriate routes in the consuming web project.
Other than that, I would be interested in a solution too.
This is a ASP.NET MVC beginner question (I'm in phase of developing NerdDinner)... I have assignment to create ASP.NET MVC cms (with its own design) and portal (also with its own design) that will display data that's being handled by CMS. I was wondering if I will have to make two individual projects in Visual Studio or I will have to use one project and place portal section in specific folder.
I know that my question is a bit premature (according to fact that I still haven't finished tutorial) but I'm bit impatient :)
On server (commercial hosting) I would use only one hosting account... this thing with URL routing is a bit confusing to me, CMS is practically also optimized for SEO.
I would like to the structure of URL to be:
---- PORTAL ----
www.domain.com
www.domain.com/Menu1/Submenu1
www.domain.com/Menu2/Submenu1/SubSubmenu1...
etc.
---- CMS ----
www.domain.com/CMS
www.domain.com/CMS/Whatever
Thanks,
Ile
It all depends on the functionality of the portal and the MVC cms.
For starters I would have a separate solution for the Model/Data Access that way you can have as many MVC projects without duplicating your data access.
From your desired url structure I would probably have the CMS as a separate controller and sub folder. Alternatively if your using MVC 2 you could look at the areas support which will probably give you a little more flexibility.
If you want the solution to be a bit more complex/flexible you have a number of options:
If both the portal and MVC cms are going to have he same functionality and page layout you have two master pages and determine which mater page to show when returning the view. You would specify this in the routing so multiple routes would point to different controllers.
If the layout/functionality differs slightly but one controller can still manage both you could have a separate controller project and two mvc projects which only contains the views, javascript and images so both mvc solutions look at your controller solution. With this option you would probable end up setting up two websites on your domain one under the root and the other under the CMS folder (in your MVC app you will prob need to block routes to /CMS so it will be processed by your CMS app).
Finally if both differ hugely have two separate projects but keep your common data access project, as above you may need to set up two sites on your hosting package.
I'm surprised I can't find more discussions out there about an issue that is really bothering me on our project using ASP.NET MVC.
How can you deal with a Visual Studio solution that has multiple projects? The MVC framework has the Models/Views/Controllers folder in the main project. But what if you want to break up your solution into multiple projects along logical groupings and bring the models/views/controllers along with it? When I think ahead to the end of the project, there will be many classes in each of these folders. It doesn’t paint a cleanly organized structure that will aid maintenance. We’d like a way to either move the classes to the projects that they relate to or at least use a folder structure to aid in the organization.
I assume that one option would be to use the same namespace in all of the other projects as is used by the main project, but I’m not a huge fan of that approach b/c this is not the approach that we’ve normally taken when defining our namespace.
I suppose we could at least create sub folders inside of the M/V/C folders and not carry forward the folder names to the namespaces. I’m assuming then that the classes could be found?
Some background on our project: It is a public facing web site that has many business transactions that the user can perform (about 50-60). Each transaction has a series of web pages that the user navigates through, in order to accomplish the different services provided by the site. We are using a single controller for each transaction (there have been long discussions on whether we should have a controller defined for each transaction or if we should use a higher level grouping and therefore reduce the number of controllers, but some information that we've encountered on the web (http://codebetter.com/blogs/ian_cooper/archive/2008/12/03/the-fat-controller.aspx) brought us to this decision.)
What are some recommendations? Have others solved this issue in a way that they are happy with?
Thanks
Jon.
Have a look at Areas.
Areas is a concept borrowed from MonoRail, which organizes controllers into logical folders.
http://haacked.com/archive/2008/11/04/areas-in-aspnetmvc.aspx
Areas are supported in Asp.Net MVC2.
Scott Gu has a blog talking about the Area Support here.
From his post.
Each area can be implemented as a
separate ASP.NET MVC project which can
then be referenced by the main
application. This helps manage the
complexity when building a large
application and facilitates multiple
teams working together on a single
application together
I always delete the "models" folder and reference separate class libraries that represent my business logic layers and data access layers. I also have some solutions where my controllers are kept in separate projects from my views. I agree that in larger applications, the single project model is inappropriate. Even in smaller apps, especially where model code must be shared with other applications, putting model classes in the actual MVC project is a bad idea.