Separating backend and front end

Is there any reason to separate front-end FE and back-end BE (for Administration and customer service) in different websites under the same solution.

Actually it causes me problems in Removing items from the cache, (they) decided to put FE and BE in different app domains, this means different Cache objects!!

I asked them about the reason and they said

1- To not be out of memory and to remove BE effect on the FE performance.

I doubt on this, Customer service team are probably affecting the centralized database performance, but there hits will be like adding 10 customers to our website, it is nothing!! Also App domain memory extends when needed, as far as I know, it does not pre allocate resources (Verify this please!!)

2- To avoid losing both FE and BE if the website goes down.

I agree but this is not a reason to put the whole BLL in a web service, what about SECURING the BLL!!!, I PREFER TO L开发者_运维知识库OSE BOTH if the IIS goes down.)

What do you think?

---

Backend and frontend are two different projects, which happen to query the same database, therefore seperate them into two different websites. Split responsibilities.

Furthermore, having different websites has these advantages:

• Secure more easily (in IIS)
• Different behaviors, custom error messages
• Processor/memory caps
• Bring down either the backend or the frontend, which is important when due to some bug the backend system drags the frontend down with him
• Different domains per project
• Easily move one of the projects to another server

Use some distributed caching system like memcached, both projects can access the same cache, though I'd rather not interact with each others cache.

At last, the BLL in a webservice is perfectly common behavior. Our backend process access an extended version of our public API which is IP blocked, and has a security token to gain rights.