N 계층 솔루션을 사용하는 데 부정적인 이유가 있나요?

Question

저는 회사에 입사한 지 2주가 되었으며 DotNetNuke의 .NET 3.5 Team Foundation을 사용하여 시스템용 새 플랫폼을 시작하고 있습니다.우리 "건축가"는 하나의 수업 프로젝트를 사용할 것을 제안합니다.물론 저는 "3계층" 아키텍처(비즈니스, 데이터, 웹 클래스 프로젝트)를 언급합니다.

이 아키텍처를 사용하면 단점이 있나요?전문가는 코드를 데이터에서 분리하고 클래스 객체를 코드에서 멀리 유지하는 등의 작업을 수행합니다.

Answer 1

꽤 큰 단점은 작성, 관리 및 유지 관리해야 하는 코드의 양이 추가로 늘어난다는 것입니다. 작은 프로젝트가 너무 과잉일 수도 있습니다.

프로젝트 규모, 최종 프로젝트의 예상 수명, 예산에 맞게 모든 것이 결정됩니다!때로는 일을 '제대로' 하는 것이 매력적이지만 좀 더 '가벼운' 일을 하는 것이 올바른 상업적 결정일 수 있습니다!

Answer 2

경험이 부족한 팀이 3티어를 구축하는 데 시간이 더 오래 걸리는 경향이 있습니다. 코드가 많아지면 버그도 많아집니다.하지만 나는 단지 악마의 변호인 역할을 하고 있을 뿐입니다.

Answer 3

작은 프로젝트라도 N Tier 방식을 적극 추진하겠습니다.codesmith + nettiers와 같은 ORM 도구를 사용하면 프로젝트를 신속하게 설정하고 비즈니스 문제를 신속하게 해결하는 코드를 개발할 수 있습니다.

새로운 프로젝트를 시작하고 "아키텍처"가 어떻게 구성되어야 하는지에 대해 이야기하면서 물레 주위에 앉아 며칠을 보내는 것은 나를 죽입니다.당신은 다른 사람들이 당신을 위해 해결해 준 문제를 해결하는 것이 아니라 비즈니스 문제를 해결하는 데 시간을 보내고 싶어합니다.초기 추진력을 얻는 데 도움이 되는 ORM(어느 것이든 상관없습니다. 하나를 선택하여 고수하세요)을 사용하면 프로젝트 목표에 계속 집중하고 "아키텍처" 문제를 해결하는 데 방해가 되지 않습니다.

결국 건축가가 단일 프로젝트 접근 방식을 원할 경우 BLL 및 DAL 폴더가 포함된 app_code 폴더를 생성하여 지금은 코드를 분리하여 N 계층 솔루션은 나중에 제공됩니다.

Answer 4

당신이 원하기 때문에 능력 레이어를 다른 물리적 계층에 배포할 수 있으려면(저는 항상 물리적인 경우 "계층"을 사용하고 논리적인 경우 "계층"을 사용합니다) 모든 것을 하나의 클래스에 넣기 전에 두 번 생각해야 합니다. 또는 배포를 시작해야 할 때.

Answer 5

추상화가 복잡성을 야기하는 모든 것과 마찬가지로 N 계층 수행의 복잡성은 적절하게 정당화되어야 합니다. 예를 들어 N 계층이 실제로 시스템에 이점을 제공합니까?거기 ~ 할 것이다 N 계층에서 가장 잘 작동하는 소규모 시스템이어야 하지만 대부분은 그렇지 않습니다.

또한 현재 시스템이 작더라도 나중에 N 계층이 아닌 더 많은 기능을 추가하고 싶을 수도 있습니다. ~할 것 같다 일종의 기술적 부채가 되므로 주의해야 합니다.

Answer 6

유일한 단점은 복잡성이지만 데이터 세트를 사용하는 것과는 반대로 일부 도메인 개체를 추가하고 그 목록에 바인딩하는 것이 실제로 얼마나 어렵습니다.3개의 별도 프로젝트를 만들 필요도 없습니다. 웹 앱 내에 3개의 별도 폴더를 만들고 각 폴더에 YourCompany.YourApp.Domain, YourCompany.YourApp.Data 등과 같은 네임스페이스를 제공하면 됩니다.

가장 큰 장점은 보다 유연한 솔루션을 제공한다는 것입니다.앱을 데이터 중심 애플리케이션으로 작성하기 시작하고 웹 양식 페이지를 데이터 세트에 강력하게 결합하면 나중에 비즈니스 논리가 복잡해짐에 따라 더 많은 도메인 중심 모델로 마이그레이션하여 더 많은 작업을 수행하게 될 것입니다.

아마도 단기적으로는 매우 간단한 도메인 개체를 만들고 이를 데이터 세트에서 채워 간단한 솔루션에 집중한 다음 필요에 따라 비즈니스 논리를 추가하고 필요에 따라 보다 정교한 ORM을 구축하거나 nhibernate를 사용할 수 있습니다.