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.
Related
VS2013 update 4, MVC5
Still relatively new to MVC. To divide functional domains within an MVC project the use of Areas seems clear from these posts (olderSOlink, newerMVC5link).
Is there ever a reason that sub-domains would be integrated as part of a solution involving different functional domains of a given MVC project? I don't have a reason to want to make use of sub-domains, I'm just asking because I don't know if there is some advantage I should know about.
Is it even possible without great difficulty? For example, can logons transfer across sub-domains? Would there be other difficult issues to address?
At present the project I am building is 'relatively' small and will have around 5 major domains so I'm assuming Areas is the best architecture to isolate these domains, but I wanted to ask for guidance before I go too far and make decisions that would make the use of sub-domains difficult in the event there is a compelling reason to use them in a single MVC project.
I generally use subdomains to separate major application functionality or if I have multiple servers that I want to be on the same domain name.
To answer your login question, if you are using the same application you will remain logged in on the whole domain (depending on your method of using sessions, the cookie will be accessible to the domain as a whole).
If you are questioning using subdomains, they are really just a naming scheme so you could categorize your 5 major applications into one domain with different paths (eg. /portal, /store, /etc..) then later you could point store.domain.com -> domain.com/store. So it's pretty flexible in the end.
I already have programmed some small applications, the database design was simple, just one normalized database containing all the datas I need for the application.
Now I want to try to programm something bigger:
There should be 4 websites build with MVC3. All the websites should use only one SQL-Membership-Database and some tables like contacts and so on should be shared between the different pages too.
Now my question is: how to start?
Should I put all the Applications into one MVC3-application and just separate them by using areas?
Is there anyone who have got tipps or experiences in creating huge (for me its huge ;-)) applications like this?
Your idea to use areas could very well work. You might need to create some custom roles to restrict access to the four areas.
You will want to do a search on asp.net mvc multi-tenancy. This link http://weblogs.asp.net/zowens/archive/2010/05/26/multi-tenant-asp-net-mvc-introduction.aspx begins a whole series on multi-tenancy.
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've been wondering about best practices on creating a project in MVC, and let others create extension/modules/plugins and skins/themes etc, for it.
For example WordPress is great at this. Just upload a file or folder. Or even browse the plugins directly from your WP administration and install by a simple click.
Does anybody here have a few tips on how to create a project that allows that flexibility.
For the skins I might need to implement my own viewengine, right?
Any good resources and tips would be great.
Thanks!
Skinning isn't that hard, just swap stylesheets. For using a different set of templates, yes, you'd need just customize, not write your own, viewengine. This is pretty easy and all you'd have to do is tell MVC to look in different places for your views:
http://www.dotnetguy.co.uk/post/2010/01/31/ASPNET-MVC-e28093-Dynamically-Changing-The-Master-Page-(Theming).aspx
The MVC plugins widgets question has been asked before:
https://stackoverflow.com/questions/2230482/asp-net-mvc-2-widgets/2230833#2230833
I ended up using a VirtualPathProvider since I wanted the views outside of the application. Now, we made it possible for the views to be stored in the database.
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.