여러 .NET 스타터 키트를 보면서 알게 된 점은 비즈니스 개체 구성이 종종 클라이언트 수준에서 처리된다는 것입니다. 그런 다음 비즈니스 객체는 조작, 데이터베이스에 대한 직렬화 등을 위해 비즈니스 계층에 전달됩니다. 클라이언트가 필요한 데이터 만 전달하면되므로이 코드를 비즈니스 계층에 추상화하면 안됩니까? 객체를 인수로만 받아들이는 CRUD 추상화가있는 비즈니스 계층을 갖는 데 어떤 이점이 있습니까?클라이언트 또는 비즈니스 계층의 개체 생성?
나는 비즈니스 계층과의 상호 작용이 복잡한 유형 및 기타 복잡한 숨김 또는 다른 점을 가능한 단순하게 유지해야한다는 점에 동의합니다. UI 및 비즈니스 객체가 연결될 때 가능한 한 복잡성이 0에 가까워 야합니다.
그 시점에서 비교적 복잡한 유형의 구성이 합법적 인 장면을 상상할 수 있습니다. 사이트가 작을수록 < 3 티어가 실제로 엄격한 3 티어보다 더 나을 가능성이 높습니다. 범위가 너무 작아 우려의 엄격한 분리가 지나치게 길어지며 그 접근법이 상황에 적절할 수 있습니다. 또는 그들이하는 일은 인데, 이것을 처리하는 가장 좋은 방법입니다. 와이어 - 업 또는 통합이 더 복잡한 경우 또는 플러그인 모델 또는 기타가있는 경우 실제로는 지나치게 복잡한 유형이 일관성있는 유연한 인터페이스를 보장 할 수 있습니다. 때로는 한 곳에서의 약간의 복잡성으로 인해 다른 곳의 복잡성이 줄어 듭니다. 그러나 더 자주 이것은 사실이 아닙니다. 내 추측은 당신이 나쁜 것으로 본 것은 실제로 그렇다는 것입니다. . . 불량. 정말 나쁜 아키텍처이
일반적으로 Service 또는 데이터 액세스 레이어에서이 유형의 작업을 수행합니다. 즉, 작은 프로젝트의 경우 내 데이터 액세스 계층에서 내 도메인 개체를 반환합니다. 큰 프로젝트의 경우 서비스 계층을 사용하여 복잡한 개체 구성과 비즈니스 논리 호출을 처리합니다.