mvc 프레임 워크를 사용하여 프로젝트를 구축 중입니다.백 오피스와 프론트 오피스가 별도의 프로젝트에
나는 내가이 내 솔루션은 단정하고 잘 구조화하기 위해 두 개의 MVC 애플리케이션
에 프론트 엔드 및 백 오피스를 분리해야합니다 여부를 결정해야 할 시점에 있어요. 그러나 동시에 장기적으로 유지 관리를 늘리고 싶지 않습니다. 2 개의 별도 프로젝트가 있거나 기본 웹 프로젝트에 Backoffice 폴더가있는 것이 더 나은 경우, 응용 프로그램이 상당히 커질 때 장기간에 대한 경험을 나에게 공유 할 수 있습니까?
또 다른 관심사는 두 프로젝트간에 이미지를 처리하는 방법입니다. 사용자가 백 오피스의 사진을 백 오피스 응용 프로그램 아래에있는 폴더에 업로드 한 다음이 사진을 프론트 엔드 또는 그 반대로 표시하는 방법
감사합니다.
"사용자의 근본적인 행동과 욕구가 다른가요?"라는 질문을하는 것이 좋습니다. 그런 다음 "백 오피스 사이트의 규모는 무엇입니까?"라고 물어보십시오. 크기가 클수록 나눌 수도 있습니다. 관리자 페이지 나 몇 장의 보고서 만 있다면 원래 프로젝트에서 같이 살 것입니다. 또한 "프런트 및 백 오피스는 다른 속도로 확장해야합니까?" 시간당 100 만회 대 시간당 20 명의 성취 직원이 어디서 번호를 올리지 않을지 결정합니다. 셋째, "프론트 오피스 고객과 백 오피스 고객은 서로 다른 보안 도메인에 살고 있습니까"방화벽 뒤에 백 오피스 코드를 배치 할 수 있다면 더 안전하게 사용할 수 있습니다.
개발자에게는 오버 헤드가 있지만 선명도, 보안 또는 단순성을 얻는 경우에는 괜찮습니다.
두 개의 웹 프런트 엔드와 공유 코드 및 리소스를 보유하는 라이브러리 (기본 데이터베이스 액세스 코드 등)가 세 개 프로젝트로 나뉘어져 있다고 가정합니다. 실제로 도우미 등을 공유하고 싶다면 3 개가 2 개가 될 수 있습니다.
저는 장점을 대부분의 경우 장점보다 중요시하기 때문에 앱을 분리하는 데 큰 도움이됩니다. Ball은 여러 가지 중요한 경우를 지적합니다. 주로 다양한 사용 사례와 보안 컨텍스트를 중심으로 진행됩니다. 나를위한 다른 큰 키커는 다음과 같습니다.
a) 프론트 엔드 세부 정보 중 일부는 여전히 논의 중이지만 뒤 사무실에서는 움직일 수 있습니다. 인터넷 익스플로러 (Internet Explorer) - 마케팅을 통해 어떤 템플릿과 색상 체계를 사용해야하는지에 대한 모든 욕구가 있습니다.
b) 앱에 따라 다른 기술을 선택할 수 있습니다. 예를 들어, SEO 및 기타 웹 비 (webby) 동작에 관심이 없으며 처리해야 할 브라우저와 대역폭 기능을 보장 할 수 있기 때문에 백 오피스에서 전통적인 ASP.NET 웹 폼을 사용할 수 있습니다.
오버 헤드 방식으로, 너무 많은 추가 작업 IMHO가 실제로 없습니다. 그리고 그 문제의 대부분은 꽤 해결할 수 있습니다. 예를 들어 이미지를 데이터베이스에 저장하거나 두 앱에서 참조 할 수있는 공통 파일 저장소를 만들어 이미지를 처리 할 수 있습니다.