인트라넷의 멀티 테넌트 또는 멀티 인스턴스 애플리케이션

Question

가까운 미래에 다른 사용자 그룹에 의해 사용되는 기존 MVC 애플리케이션이 있습니다. 기존 및 신규 사용자 그룹/프로그램 모두 독립 데이터를 갖습니다. 나는 두 개의 사용자 그룹/프로그램을 구별하기 위해 테이블에 플래그를 추가하려고하고 각각의 데이터를 끌어 올 때 응용 프로그램에 액세스 할 때 일부 라우팅을 수행하려고합니다.

이제 코드 사용자 정의와 관련하여, 예를 들어 한 그룹/프로그램이 첫 번째 그룹이 원하지 않는 페이지에 추가 필드를 갖기를 원하거나 응용 프로그램의 프로세스 흐름이 두 사용자 그룹 사이에 분리되어 있습니다.

위의 두 시나리오가 자주 발생하면 각 프로그램/사용자 그룹의 코드를 사용자 지정하는 대신 새로운 웹 및 데이터베이스 인스턴스를 수행해야합니다. 이 방법으로 내 고객/사용자 그룹 모두 응용 프로그램에 다른 논리/필드를 추가 할 수있는 유연성을 갖게됩니다.

비 멀티 테넌트 방식에서 볼 수있는 유일한 단점은 개발자가 두 개의 개별 응용 프로그램을 유지 관리해야하는 시간입니다. 나는 각기 다른 사용자 그룹/프로그램에 대해 동일한 코드 기반을 사용자 정의하기 위해 경쟁 논리를 추가하는 것에 대해 무서워합니다. 인프라 비용은 문제가되지 않습니다. 또한이 응용 프로그램은 2 개 이상의 사용자 그룹/프로그램에서 언제든지 사용할 수 있습니다. 그럼 내가 너에게 어떤 apporach를 가져야하는지, 왜 그렇게 생각하니? 모두 미리 감사하십시오.

피씨 사용자는 다른 테넌트 데이터를보기 위해 사이트를 해킹하려고 시도하는 닌자가 아닙니다. 그들은 기업 사용자입니다. Theyd는이 애플리케이션을 사용하지 않고 프로세스의 일부만 사용하므로 사용해야합니다.

Answer 1

멀티 테넌시에 대한 Microsoft의 article을 살펴 보는 것이 좋습니다.

저는 또한 각 클라이언트가 별도의 필드와 사용자 정의 화면을 가질 수있는 아키텍처로 mvc 응용 프로그램을 설계하려고합니다.

결론은 멀티 테넌시 지원과 함께 IOC 컨테이너를 사용하면 모든 일이 훨씬 쉬워 질 것입니다.

Autofac에는 multi-tenancy support이 내장되어 있습니다.

각보기에서 클라이언트에 대한 논리를 갖는 관점에서 IOC 경로를 아래로 내려 가면 각 세입자에 대한 컨트롤러를 가질 수 있으며이 경우 하드 코딩은 이러한 클라이언트 특정 논리가 반드시 그만큼 나쁘지는 않습니다. 모든 것을 공유 컨트롤러에 하드 코딩하도록 할 것입니다. 본질적으로 저는 특정 세입자를위한 구성 요소를 작성할 때 그 세입자가 시스템을 사용하는 유일한 사람인 것처럼 사고 방식을 전환 할 수 있다고 믿습니다.

뷰를 사용자 지정하기 위해 방문한 다른 솔루션은 각각의 테넌트보기가 별도의 어셈블리로 컴파일되고 (this 기반) 내 자신의보기 엔진을 만든 컴파일 된 뷰에 대해 RazorGenerator 접근 방식의 변형을 사용하는 것입니다. 내가 라우팅 매개 변수의 값에 따라 뷰를 찾는 어셈블리를 바꿀 수 있습니다.

물론 나는이 접근법을 여전히 탐구하고 있으며 부족한 부분을 찾아 내기 위해 완전히 제거하지 않았습니다.

Answer 2

2 명의 사용자 요구 사항의 차이가 화면/기능의 10 % 이상인 경우 2 개의 데이터베이스와 앱을 사용하는 것이 좋습니다. 10 % 미만으로 예상되는 경우 기능이 다른 부분에 대해 별도의 작업 (액션 이름에 다른 접두사 또는 접미사가있을 수 있음)을 작성하십시오.