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.
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.
What are some strategies for managing the url routing in a large (100+ controllers and growing) MVC project? Areas has been helpful, but their usefulness seems limited because they can't nest. As the project grows, I've noticed a few big pain points:
SEO-friendly routes (every seo route needs a special definition)
Redirection for legacy routes (need to 301 old urls to the updated equivalents)
Testing routes (is there something better than manual testing and lighter than selenium?)
Also, doesn't performance degrade as the number of routes increases? The way routes are defined suggests performance is at minimum O(n*k), where n is the number of defined routes and k is the length at the url.
A couple of questions to consider that may make this easier for you:
Is there shared functionality between the controllers?
Is there a way to create a generic pattern for your controller and use some of the events raised by a controller to provide generic functionality (i.e. pulling data from a DB in a consistent pattern)?
What is fundamentally different between each controller?
The reason for these questions is that I see a couple of potential solutions:
Assuming you're running on IIS 7 or better, then you could break your functionality into multiple MVC projects for each area. This becomes much easier with IIS 7 and higher (for deployments that is).
Assuming a consistent pattern of presenting your data, a generic controller or route could make this much easier, allowing you to collapse your controllers.
A base controller would allow sharing functionality while presenting the specialization you need for each individual controller.
All in all, I would recommend trying to break your code base into multiple MVC projects, based on purpose, to help establish that sense of sanity which seems to be slipping away as your project continues to grow.
i want to develop a simple CMS.
i want to add the ability to add modules to the CMS.
what need to be the architecture for
such a CMS?
a solution and then a mvc project
for the site and another for the
admin? or one project with area for
the admin?
in mvc each of my modules will have a controller,model and views. if i will put all in one project, then i will mix of all module ,each module will be in 3 folders (controller,model and views).
how i need to arrange them so my code will be nice and clean?
Since you are only separating by type of user, you can surely (and easily) include in one project. all of your Admin controllers should have [Authorize(Roles="Admin")] on them to limit them only for the admin. Mixing them is fine, other applications mix user roles in an application on a regular basis, just limit the difference by security (and dont use url restrictions in your web.config - use the [Authorize] attribute on your controllers instead!!
If you expect the differences in both applications to be huge then you can separate into another project, but I'm imagining you can get very good reuse by including them in the same project.
How to architect this is a very very broad question. For a basic project some include everything all in one project. I prefer to break out all my models and data access code into a separate project and try to code to interfaces as much as possible for unit testing purposes. I think that is all a bit beyond the scope of the posting here though. To start - work with the mentioned attribute and I think you will develop. Start unit testing early and I think that will help steer you into the right direction. Also read up on dependency injectiom , unit, ninject, etc for ways to dynamically bind to your implementation classes as this makes your unit test go quite a bit smoother as well.
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.
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.