Multiple websites from a single service and model layer

I want to do something similar to stackexchange but with their own domain. I want to have 1 single database, repository/model layer, service layer on 1 server. Then on a different server or same server, I have a web project which can access those layers.

Is there a way to achieve this without a hit in performance on these sites? I'm thinking about just providing a WCF service, but with that generating and reading xml, it seems slow. What other way may I accomplish this?

What does stackexchange do?

---

This is a simple architecture of what I want to accomplish:

Each other UI may or may not have their o开发者_运维百科wn Database.

My goal is:

I want to provide a set of service for sites we'll be developing for a set of people. I want all of these relevant data in a single database. But each one may need separate logic/database. I'd like each user on each site to have their own authentication. I also would like my service layer to differentiate which domain the request it coming from.

---

Is there a way to achieve this without a hit in performance on these sites?

On the sites? Don't you mean on the shared Service?

You're quite correct in that parsing lots of XML will be slow, but WCF can bind in different ways, so you aren't explicitly tied to parsing XML.

More generally, if you're mindful of performance:

• Deploy everything onto the same server - save yourself a hop cross the network.
• Don't connect remotely go direct. Use Dependency Injection to load up a provider dynamically, so you can still manage dependencies. Another spin-off is that you're code will execute on the same process so you won't even have to hop across processes.
• Consider caching.

This is just off the top of my head, I'd also suggest searching StackOverFlow by tag - specifically the performance tag and any others that take your fancy: https://stackoverflow.com/questions/tagged/performance+.net

Edit: Oh, I almost forgot: It also sounds like you're getting into Multitenancy; you might want to check out:

• http://en.wikipedia.org/wiki/Multitenancy
• Multi-Tenant Data Architecture

I included the data architecture one as you mentioned databases quite a lot, this might give you some good food for thought.

Edit:

I still dont understand how I would upload a new web project that will utilise the same process that the main system is using

Same process or same functionality / data?

I'm guessing it's the functionality and data you want to re-use (by process I thought you meant same physical process of execution); in which case it's easy - make one component and deploy/use it many times.

Lets say your shared service is a database, and sitting "on" that is some .Net component that does the actual data access, and which exposes some sort of interface / API.

Options 1: Direct Consumption

• Copy the necessary DLL's into your new wep app
• add the necessary config, reference the services managed code.
• Have your BL code directly use the service API.
• New system: repeat.

Here you have one component but multiple instances of it - one for each web app.

Pros:

• Fast to set-up, assuming the service already has an API you can use and is in a state that is deployable as discussed.

Cons:

• You've 'hard-coded' yourself to a dependencey; and if you do it to multiple projects you'll have a nightmare making changes to the service's underlying data (for example) - because it'll affect all the web apps who consume it.
• You core BL code directly consumes an external component, this code will be scattered all through your BL - pray you don't need to make significant changes.

Option 2: Adapter

• Same as Option 1 except that your BL code doesn't reference the service, nor does it's code directly use the service API; instead make a new package (project/assembly) that does all of this for you, then have the BL go through that.

Pros:

• Not quite as evil as option 1, you now have some degree of isolation between your core system code and the service.

Cons:

• The same as option 1, except your code is much much cleaner.

Option 3: Dependency Inversion (DI)

• Similar to option 2, except the adapter is now an abstract interface and the web-apps don't reference the service directly; they will reference the assembly that contains the interfaces - but that's pretty much all that assembly will hold.
• You'll probably end up also defining a common assembly that has common types used by your system - commonly known as Plain Old C# Objects (POCO's).
• The idea is that the interfaces and POCO assebilies won't change much (see the Stable Dependencies Principle and Stable Abstractions Principle, both are referred to in the DI article linked above)
• The interface needs to be referenced by both "sides" but is owned by the service - so the service defines it. When you're designing the service you can obviously still design it with the specific needs of your web apps in mind.

Pros:

• Complete separation == better dependency management.
• Easier re-use via a well defined interface.

Cons:

• None really (?)
• It might take more thinkingon your part and more effort to get this set-up, but once you're there you'll be on a much better footing, and so it will pay off.