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.
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 been practicing developing an application in .NET and with other languages and server, and now I want to start sketching out an architecture I want to implement.
The reason why I want to separate the two is because I cannot focus on a specific thing when everything is Jumbled into one server. I would like to be able to have the freedom to offer features that would otherwise bottleneck one server and not another(ex. notification, chatting)
What brought me here to ask this question is because I am totally confused on why everything on the UI is always called MVC. When searching for solutions to a distributed architecture that I can implement I keep running across frameworks that use an MVC pattern.
How does this actually work when you already have your API models? Isn't an MVC pattern just going to duplicate all of the models on the API (ex django, asp.net mvc or ruby on the rails)?
One scenario that threw me off and brought me to research a whole lot more, is when I wanted to create a registration form that has steps, validating the username uniqueness was on one step and zip code was on another. I found myself wanting the tweak the API based on how I wanted to present my view and thought about having to do that for different types of clients(mobile, different user agents) and quickly backed off that idea. The problem is those fields need some sort of call to the back end and every view wont have that way of registering.
The main question is how do I implement a UI layer that I can customize toward certain views, without changing the way my API is structured?
You might be interested in this article from LinkedIn dev team.
https://engineering.linkedin.com/frontend/leaving-jsps-dust-moving-linkedin-dustjs-client-side-templates
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'm pretty new to ASP.NET MVC and I just want ask of this scenario is possible and, if so, could anybody provide any resource links on how to implement it.
Say I have a site that can be accessed from www.mysite.com, can I also have the same site load up through www.mysite2com, www.mysite3.com and so on? effectively providing the ability to run multiple sites from a single code base?
The idea is to have the site content and style sheet change depending on site visited but keep the structure the same.
thank you very much for any help you can provide :)
Kris
Yes, this is possible
http://web.archive.org/web/20100119084358/http://just3ws.wordpress.com/2010/01/03/skinning-your-asp-net-mvc-application-based-on-your-sub-domain
This example uses subdomains of the same domain but nothing stops you from using the same logic and have different images/CSS/paths etc generated based on full HOST/domain name
We have 3 websites at the moment that all operate off the same database backend and they share almost 100% of the business logic.
It is becoming a pain to have to update 3 website's code every time to accommodate a small change. Would using ASP.Net MVC work for us?
What I am thinking is the business logic and database is almost identical in all 3 so extract that away into the Model and the Control. Then each web front end (which looks different) each has a different View. It would then be Nice to have a single project where we can have all the code for the Model and Control shared. And 3 different views.
How would we deploy something like this? Share a single codebase for Model and Control and have 3 separate URLs using 3 different Views. Or is there a better way to do this?
You can probably pull it off using ASP.NET MVC, but you could also insert a service layer and use standard ASP.NET web services to expose it. Then each of your "views" could still be in its own little world, and just use the web services to grab and persist data.
ASP.NET MVC is probably a better solution in the end, but this is certainly an alternative.
One thing you do need to consider is if you want to keep these 3 sites on seperate domains. I'm not sure how ASP.NET handles keeping different views on different domains.
Sounds like you really need to implement a service layer (encapsulating the common business logic and data) that is used by n (thin) web apps. So think SOA.
This seems reasonable to me. In terms of the model and control you could consider dealing with any minor differences between the current models/controls using shared functionality in a base class and using inheritence to deal with exceptions.
If your web front end is only different in terms of look and feel then you may want to consider using the same code base but just swapping in different themes using CSS.