I've done a large study into using MVC and thanks to the people here a lot of the issues revolving around it have been cleared up for me.
The problems I'm having now revolve around the sheer size of our application and how it would be organised within the project itself. For example, we have url's such as http://mylocalapp/folder/nestedfolder/subfolder/theapp. The reason we do this is because the application quite literally is that large. We need that kind of folder structure because otherwise the application would be unmanageable.
Phil Haack covers the registering of routes for nested folders in one of his blog posts which is very useful indeed, but our application has sub-applications and sub-applications within that. It couldn't be simplified any further.
What steps need to be taken to manage such a large application which spans a large amount of folders and has folders up to seven levels deep, as well as having about 15 databases? Is MVC really the answer for an application of this size?
Is another option simply to apply lots of URL routing and map route areas for all the separate sub-folders?
If you don't need to have everything inside of one application, why not create an MVC application in each folder?
I have a similar situation and what we did was instead of making a "fat" controller, we make them "skinny". Ian Cooper has an excellent write-up here.
So what we did is we broke down the "sub-applications" to be its own application. I think this is what the previous posters trying to convey as well.
As per a comment "Are you refering to "Areas"?" was the answer eventually.
Related
I come from an Asp.Net background and I'm evaluating Asp.Net MVC for a new project. I can't see how to structure a large project adequately.
I'm happy with the Model/View/Controller architecture and I'm presently trying to get Areas to work (which seems quite complicated for what it is).
Can you have Areas within Areas?
Can you put Views in dlls?
I really need a starting point here, are there are resources which show how to structure large MVC projects, assume that eventually there will be 100+ views in the project, I don't want them all in the same folder and ideally I'd like sub folders
thanks for any help
Edit:
I can see that each controller maps to a View folder, what I want is something more like this
Areas
Mail
Absence
SimpleAbsenceController.cs
ComplexAbsenceController.cs
Overtime
SimpleOvertimeController.cs
ComplexOvertimeController.cs
Etc
Edit2: Perhaps this is more of a routing question, can I map from:
http://www.mystuff.com/SimpleAbsence/Index
to Mail/Absence/SimpleAbsenceController
Fundamentally I want a way of structuring my project into folders
I hate answering my own question as I feel it undermines the work of others who try to help, at the same time others may look at this later and these really are newbie questions, so...
(this is all from reading Pro ASP.Net MVC5, good book)
I wanted to know how much flexibility there is in Asp.Net MVC with regard to using subfolders or dlls. This answer address the subfolders question.
Answers
You can put controllers where-ever you like in terms of folders on the disk, these are compiled, but...
When you use areas the MapRoute in the AreaRegistration.cs file automatically limits
the routes to the namespace for the area. So if for example you move a controller to an area you -must- change the namespace or methods like Url.Action will fail
Views must stay where they are, so for a controller called Fred there must be this structure:
View
- Fred
- Action1
- Action2
- etc
You can work around all of this using your own routing system, you could probably work around the namespace issue with a custom route, but my view is as a newbie you should work with the system until you know enough to fully understand the consequences of breaking the rules
So this means you could have a large project with a few hundred Views all lumped together in one folder. It's not quite as bad as it seems as the controllers can be in sub folders and you can directly map from them to the Views.
You also have flexibility in the routing system, so regardless where controller are on disk you can have any urls you like!
e.g. this route maps from
http://www.example.com/App/DoSomething to
http://www.example.com/Home/Something with no changes necessary
routes.MapRoute("NewRoute", "App/Do{action}", new { controller = "Home" });
NB If you do this make sure to use Html.ActionLink or Url.Action (or equivilents) as opposed to direct links, these are clever enough to generate the correct urls based on the routing.
As I say, complete newbie issues but I'm sure others will have the same questions, thanks to MiniRagnarok for his example of a real life project
What we're talking about here is very opinion based. I've seen people that prefer to have lots of Controllers with a mapping of every object to a Controller. I've also seen people that prefer to have tons of Views. So my example is what our team has decided to do and not necessarily the same as you would see in sample tutorials.
Take a project we did that has 200+ Views for example. The site is an auction and retail site.
Controllers
AccountController.cs
AdminController.cs
AuctionController.cs
HomeController.cs
PhotoController.cs
StoreController.cs
SupportController.cs
Views
Account
DisplayTemplates
EditorTemplates
ChangePassword.cshtml
_Favorites.cshtml
Settings.cshtml
Admin
Auction
Home
Photo
Shared
Store
Support
For us, we name all partial views with an underscore first. We also utilize DisplayTemplates and EditorTemplates. All of this really helps us keep things separate. You'll notice that our controllers are split by role or function. We were never bothered by the fact that there are many ActionResults within our controller since all of our logic is really in the models.
I have learned much and solved a lot of problems coming up with multi-tenancy.
But one problem still exists. I have to offer a tenant-specific resource file because our customers want some text a little different then other customers.
Is there a way to implement a multi-tenant resourceManager? I haven't found anything else in the www.
We needed the same functionality in a web forms project and ended up implementing our own IResourceProvider, finding inspiration in http://msdn.microsoft.com/en-us/library/aa905797.aspx. That way we could have files like Default.aspx.rex, Default.aspx.da-DK.resx and Default.aspx.da-DK.xyz.resx, where xyz was the customer name. This worked quite well. Going this way seems to imply using the App_LocalResources and App_GlobalResources folders.
However, those folders are not the MVC way of using resources and will cause problems. For instance, they will not work properly with unit testing. As a last resort you might find it useful though.
I'm getting started on a large Rails project that will consist of several independent areas including and admin area, front-end website, user area, and api.
Would it be wise to create say, 3 namespaces for these sections (leaving the front-end website as the root)?
There doesn't seem to be a general rule regarding namespaces and it seems like the right choice for organizational purposes since each area would require several controllers.
In my past Rails projects I always namespace the admin, but in this case, are there any drawbacks to having multiple namespaces in the long run (in regards to routing / interacting with other namespaces)?
Any advice would be much appreciated!
no drawbacks only advantages if the namespaces make sense. Obviously having too many namespaces might be confusing and pointless but breaking up admin/client/public is a pretty common use case for using namespaces.
just make sure you give all your controllers unique names, so you don't run into the problem this guy ran into with namespaces: http://blog.philburrows.com/articles/2008/05/02/rails-namespaces-rock-rails-namespaces-suck-/
If your project really does consist of logically independent areas then I don't see a downside. Any routing situation can be implemented with minimal effort, so that's not a dealbreaker.
One think you will have to keep in mind is that your project is going to have one extra level of directory nesting. For example, you can't just look in the views directory and get a good idea of all of your views, because they will all live in directories corresponding to their namespace (the same goes for tests). This is often desired, however, as it helps things stay a little more organized.
checkout http://www.ror-e.com and the github app https://github.com/drhenner/ror_ecommerce It has several namespaces and most namespaces have their own base_controller.
When you start creating an application or site in ASP.NET MVC, what do you do before typing in that first line of code?
I'm personally fond of creating a new ASP.NET MVC Web Application project and then cleaning out controllers/views until I have what is essentially a blank project (i.e. it runs but doesn't offer functionality). Then I start working on my model and adding controllers/views as needed.
I've also read about starter kits and sample applications but I have not yet started actively working with any of them. However, in my reading I have seen authors suggest that it might be good to start off with an existing template and build on it.
I'm trying to determine if there are better ways of starting off a project such that time is saved and/or the resulting deliverable is of higher quality.
The other things I do (I also clear out the controller/views etc)
Put an IOC in place.
Put ELMAH into the project.
Then I grab a coffee and write my first test.
Kindness,
Dan
PS: At some point I shall get around to creating a template for this so I don't redo it everytime. As soon as I decide upon my favourite IOC. :-)
I usually clear out the Content folder as well and put in place a nice CSS reset file and/or a CSS framework like the 960 grid
Before starting any type of project you must know what you want to do. So take a sheet of paper and start writing on here:
The name of your application
Enumerate the features
Make a quick draft of the domain model (entities that you are going to have)
Try finding the ways (choosing a technology) you are going to do different stuff like: data access, validation (client and server side), logging, IoC, Security, Caching etc.
Do a quick draft of all the views you are going to have in your application
Identify any other problems you might need to solve/implement/develop and think how are you going to do that
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.