I have got a requirement from a client. They need three blogging web application for three different regions. Each application have its own data and posts. Probably they want to share user information between these applications. User interface of these application will be same except css level changes (color, font and styles) and little bit layout changes in home page for each blog. That brought lot of questions to my mind.
Three seperate site approah
1. Is that good to develop three different websites for each region and deploy them in three subdomains?
2. Am I going to use same database or individual database for each region?
3. If there are three web sites, how am I going to overcome caching, session sharing and user signon(single sign-on), multiple deployment, duplication of code issue?
Single Site Approach
1. Create a single site, seperate the regions like sitename/regionname?
2. If it is single site, how the performance and scalability is going to be?
3. Just use singe database, that would be shared between three regions. Is that good approach?
There could be many more possiblities. Now I need your guidance that what are all other unknown problems would occur and how would I approach this problem one by one and come to a conclusion that which is best?
We may implement this solution in C#.
EDIT: The sites will be in English language
You have a lot of choices to make here, so you need to get some good information from the client.
You mention that there will be layout changes between the sites. This part right here says that you might be better off with three different sites for the user interface. It's probably a good assumption that they are going to want to change the UI's to each site on an individualized basis. Building all of that into a single engine is difficult.
All three could share a single database, you just need to make sure that each post, config piece, etc all have a SiteId associated with them. Also you'll need to make sure that every query you write uses that SiteId value. This situation is called a Multi Tenant architecture.
Caching will be handled just like caching for a single site.
After writing all of this, it occurs to me that you might be better served by simply taking an existing product like WordPress or something similar and creating templates for it for your purposes.
I've had a similar design-issue recently, so let me share with you my approach (however wrong or right you think it is!). I went with a single site, single database coupled with host headers.
The first thing I did was to create a domain table. It kind of looked like this:
_domains:
_id INT IDENTITY NOT NULL
_domain_name NVARCHAR(255) NOT NULL
_id_category_root INT NOT NULL (foreign key to _categories::_id)
This allowed me to specify a top-level domain for content categories. Content categories belonged to the domains.
_categories:
_id INT IDENTITY NOT NULL
_category_name NVARCHAR(64) NOT NULL
_id_parent INT NULL (foreign key to _categories::_id)
_theme_root NVARCHAR(64) NOT NULL
The _theme_root field specified the default theme folder within the root. This allows each category to (optionally) have a different css and, if it so desires, a different master page. This allows content categories to look completely different (CSS, images and layout) or even just the CSS using the default master page.
And, thusly, content belonged to a category:
_id INT IDENTITY NOT NULL
_id_category INT NOT NULL (foreign key to _categories::_id)
_content_title
-- other fields
I abstracted it this way because you can have multiple domains for the same category level:
enGB.mysite.com -> category 1
www.enGB.mysite.com -> category 1
frFR.mysite.com -> category 2
etc
In my code, I look at the host header and pick the category appropriately, serving content and other tables that branch of that made category table. If the host header does not match, I fall back on a default (The english site).
EDIT: Added notes on theming.
It is not good to develop 3 different web sites. The maintenance will quickly become a nightmare and the code will be very cumbersome.
Break it down into Services (SOA) Service Oriented Architecture. This is language agnostic. So if you use C#, PHP, Java, or Python the general idea is the same.
1.) Create a User Service to authenticate users.
2.) Create a Blog Service to handle storing, retrieving, and editing blogs.
3.) Create a single site to communicate with the services and use localization.
Using a service has the added benefit of being able to change the database design, DBMS, etc... without having to change the core application.
In the User Service store some kind of local identifier so that your single site can change based on localization rules. All the major languages have localization settings to do most of the work for you such as date format, currency, etc...
Note: It is best to get the Region name during the User Registration - not the Sign-In.
A design like the one described above makes the code much easier to maintain - compared to 3 separate sites.
It should be a single site, and it should be a single database. Scalability is a whole other issue of it's own. What kind of traffic are you expecting?
Anyways, take a look at nvidia.com, this site is setup for different regions across the world. It's still all the same website in most cases. Some parts may be hosted in different countries, but they are probably connecting to the same database or set of synced databases.
The other most important thing, is do you want all the sites to be exactly the same but just in a different language? If so this will just be simple text replacement, or your database would just be setup to where your application can easily switch out content from different languages.
Your project certainly needs a lot of time in the planning stages. You need to make sure you know exactly what your client needs because that can often be different from what they want. Plan some options for your client and present the pros and cons of these options. Then let them decide.
There may be a single site... and with that single site u can also use it with different url ...
My Mean to say website is a single and all users uses this site with different url so they fell that they have their own site .. but actually there is only one site.....with one database ....
its possible .. and its a best way .....
Related
I am testing out Identity for my ASP NET CORE MVC application. From what I have read the Identity solution provided is probably the way to go now considering user management and security for logins.
What I have not yet understood is if it is somehow possible to combine the Identity solution with custom groups?
Let me explain..
Lets say I create a webpage for Factories.
This means that several customers that own these Companies that run the factories would like to use this system.
Company A has 3 Factories with 100 workers on each factory.
Company B only has one factory with 20 workers on that factory.
I have read alot of roles and that of sort on how we could seperate these by roles. What they can see, what they can do. But how in the world do I isolate Company A from Company B?
The old fashioned SQL table way would be like to have a Users table, a factory table and a perhaps Customers table. And from there build the logic. But with Identity it does not seem to work in that way?
Any suggestions or links to further reading about this would be appriciated! And even if you guys know that Identity is not the way to go for this kind of solution, then be it. Just so I don't waste any time on something that perhaps is not meant to be.
There's a lot to unravel in your question, but I'll give it a shot. At a high-level it sounds like you're looking for a multi-tenant system.
and pretty much everything you're saying is on point, you probably just need an example to get going. If so, check out Microsoft's example of a multi-tenant system. It might be enough to get you going.
There's several different approaches to a multi-tenant system depending on your business requirements, but here's a few of the more common approaches I've seen used:
Database Isolation - Each Company would be in a separate database. When a user from Company A connected, you would be able to look up which database/schema you should connect too.
Row Level - All companies store data in the same tables, but there's a column called something like "company_id". Every time you query against the table, you filter on company_id based on which user is logged in.
Instance per tenant (AKA Standalone) - On this approach you essentially have multiple web servers running, one per company. They are completely isolated from the web server all the way down to the database. This can be desirable in some situations, but requires a bit more hardware. On the code side, you can handle this fairly effectively with just moving relevant settings into the appsettings file.
Further Reading:
Identity Management In Multitenant Applications
Multi-Tenant Patterns on SQL Databases
Row Level Multi-Tenant Example
The implementation for the different companies changes depending on how you decide to implement the multi-tenant system. So it's hard for me to give you any concrete advice on implementation.
The only word of warning I'd give is think through the relationship between a user and a company. That could change/complicate your implementation fairly quickly.
Can a user be part of Company A and Company B at the same time?
Hope this helps a bit, and best of luck.
I have a C# project called Authentication that allows users to login and get their login credential checked and if passes, returns the token.
I want to reuse that C# Authentication project for other Applications that I am designing. Is it a good practice to store all the users from different Applications in one table or is there a better way to go about coding for One Authentication project for many Applications?
It depends.
There is a difference between code reuse and infrastructure reuse. The former is OK as you get a clean separation between the applications. Sharing a database is not recommended as it can introduce security vulnerabilities if you do not design it carefully.
I would also separate the notion of users and accounts. An account is used to log into an application and load the correct permissions. i.e. the account controls what an user can do in an application while the "user" object describes the user itself.
If you separate it like that, it's much easier to create a reusable library as everything related to authentication/authorization is in its own part. That's because the authentication design rarely changes. What differs in applications is typically the information that describes the user and the kind of customization that every user want to have.
Short answer:
Separate everything related to authentication and authorization into an "Account" object.
Collect everything describing the user into an "User" object.
Reuse the account part, but build the "user" part in every application.
Never, ever share the database between services. It will create a maintenance nightmare.
Every DB should be designed around (and after) the Bounded Context handled by the relative microservice.
In your case this means one DB to store the authentication data, then another DB per-service, with the relative data.
It is perfectly fine to have a Users table in separate DBs holding some duplicate data. As long as you're diligent enough and have a good strategy for keeping that data in sync.
I am developing an app with the potential for a large number of customers. Each customer will need access to only their information. However, this information will be regularly accessed through the day and mustn't be shared with other customers. Whilst I am intending on using Azure to share a single database, I can't decide if I should use one website to cope with the uses and have them log in, or provide each customer with their own Azure website; probably with authentication in any case.
Cost, of course plays a part in my decision, but it would seem that having a single web solution would make updates, bug fixes, etc, easier to deploy once, instead of one for each customer. Each customer being separate will mane that they don't have to all be running the same version though.
The images will be stored on an Azure Storage account too.
Does anyone have any experience of this sort of multi-customer deployment scenario or a particular view that I might have missed?
Many thanks,
Jason
I would say you touched all major issues:
A single site is easier to maintain.
Licenses might be cheaper for a single site than for multipule sites.
A single site enforces one version to all clients.
So I guess its a matter of priorities.
On a related note: while using a single DB to all costumers is easier to maintain and cheaper,
it might lead to nasty bugs , so I would take that into consideartion as well.
I have a asp.net web project named FinanceTracker (which is under use for an year).
And the data is stored in Finance_Tracker_db.
(this is a intranet web site to track the financial data for an organization, accessed from
http://OrgTracker)
Now I have a requirement to have the same application for IT department.
everything is same on the data for both should be segregated.
So I created an empty copy of database name IT_Tracker_db.(on same database server)
And used the old code with modified connection string in web.config
(accessed from http://OrgTracker/IT/ deployed on same IIS server)
But as to have less maintenance to apply the same code to both deployed version, I am planning to use the same code with different connection strings.
Now I wish to have something like.
http://OrgTracker/ - This should show two links
http://OrgTracker/fincance/
http://OrgTracker/IT/
And based on user selected URL the proper connection string should be used from web.config
Like all pages will remain same like.
http://OrgTracker/fincance/Status.aspx, http://OrgTracker/fincance/Inbox.aspx, etc.
http://OrgTracker/IT/Status.aspx, http://OrgTracker/IT/Inbox.aspx, etc.
Can have more than one config
ASP.NET Configuration File Hierarchy and Inheritance
I suggest not doing this. First, it is complicated and out of build-in ASP.NET functionality.
Second, in some time in future your users can demand different things: one department would want newer version immediately, while the other one would want to have stable old version until they can test everything.
P.S. But if I were you, I'd start thinking about adding additional column called "Department" in all relevant tables so I could unite databases in future. This goes against my second point :), but it would make everything more manageable and architecturally sound, especially if more departments would want to use your application.
Good afternoon - I have a pretty general question today - I've been tasked with creating a web application to manage some basic information on customers. It's a very simple application, but what I don't know is what to keep in mind to develop the site around supporting multiple users at their own domains or subdomains of our url?
How would I restrict users from logging in to each others portion of the app?
I've seen mention of database scoping in similar questions on Stack Overflow, could anybody elaborate on best practices for an implementation like this?
Are there any new features in MVC3 to support multi-tenancy? I am facing this issue with MVC2 and my eCommerce site where we decided we wanted it white-labeled and customizable for multiple shop owners, and don't know where to begin in implementing these features in an existing application. Any input is appreciated.
edit
To elaborate on multi-tenancy, what I mean - in the context of a store for example, multiple users sign up for their own store at www.mystore.com and are each given a unique subdomain to access their own instance of the store, at user1.mystore.com, user2.mystore.com etc. Each store would have customers with order histories, and those customers would have logins. I would need to restrict customers of user1.mystore.com from logging in at user2.mystore.com without a new account, and likewise prevent user2.mystore.com from accessing user1.mystore.com's customer history.
I implemented a complete MVC multi-tennant app. Here are some links I found handy and some sample apps:
http://msdn.microsoft.com/en-us/library/aa479086.aspx
http://codeofrob.com/archive/2010/02/14/multi-tenancy-in-asp.net-mvc-controller-actions-part-i.aspx
http://www.developer.com/design/article.php/10925_3801931_2/Introduction-to-Multi-Tenant-Architecture.htm
http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_cc
http://lukesampson.com/post/303245177/subdomains-for-a-single-application-with-asp-net-mvc
http://code.google.com/p/multimvc/
http://www.paulstovell.com/widgets
http://www.agileatwork.com/bolt-on-multi-tenancy-in-asp-net-mvc-with-unity-and-nhibernate/
http://ayende.com/blog/3530/multi-tenancy-approaches-and-applicability
http://weblogs.asp.net/zowens/archive/tags/Multi-tenancy/default.aspx
http://cloudsamurai.codeplex.com/
http://cloudninja.codeplex.com/
http://msdn.microsoft.com/en-us/library/hh534484.aspx
http://blog.maartenballiauw.be/post/2009/05/20/ASPNET-MVC-Domain-Routing.aspx
http://blog.tonywilliams.me.uk/asp-net-mvc-2-routing-subdomains-to-areas
Even starting from scratch, you are in for a world of hurt. The MVC framework does very little to help you address the issues.
Most likely you are about to spend a fair amount of time restructuring your database.
The first step is that you are going to create a table to house your "Tenant" list. Then you need to add this TenantId to just about every table in your system to make sure no one steps on each other. You can skip any tables that are global in nature. One example might be a list of Status Codes.
However, everything from users to the data they have etc will have to have this ID. Also, modify all of your indexes to take tenantid into account.
Once you have that, you'll need to modify all of your queries to take the tenantid into account.
One column of the tenants table should be the portal url. Like customername.oursite.com or whatever. This way you could point multiple urls to the exact same code. When the site needs to use the current tenantid just look it up based on the URL the passed in.
If I was doing this, I'd plan to spend about 1 to 2 hours per table in the database to make it "multi-tenant". Obviously some tables (and their queries) will go faster; others will take longer.
Incidentally, this doesn't cover things like customizing the UI (look / feel) per tenant or anything of that nature. If you need to do this then you'll have to either create a directory on the server for each tenant to hold their style sheets or load it directly from the DB (which has it's own issues with regards to caching).
Typically, you design for this at the beginning of the project. Refitting an already (or almost) complete project is a PITA.
Finally, test, test, test and do more testing. You will have to make sure that every single query pulls only the data it absolutely needs to.
There has been some talk of multi-tenancy support in Sharp Architecture (based on MVC 3) found here: http://www.yellowfeather.co.uk/2011/02/multi-tenancy-on-sharp-architecture-revisited/
Not sure if that really helps you with your existing application, porting over would be a bit of a job.