N-Layered 데이터베이스 응용 프로그램 ORM을 사용하지 않고 UI가 표시해야 할 데이터의 요구 사항을 어떻게 지정합니까?

Question

여기서 포인터와 정보를 찾고 있습니다. 정답이 하나만 없다고 생각하기 때문에이 CW를 만들 것입니다. 이것은 C#을위한 것이므로 아래 LINQ에 대해 언급 할 것입니다. 긴 게시물에 대해서도 사과드립니다. 여기에 질문을 요약 한 다음 전체 질문이 다음과 같습니다.

요약 : UI/BLL/DAL/DAL/DB 4 계층 응용 프로그램에서 사용자 인터페이스의 변경 방법, 더 많은 열 (그리드로)을 표시하려면 비즈니스 로직 레이어를 통해 데이터 액세스 계층으로 누출을 피하십시오. 데이터를 표시 할 데이터를 보유하십시오 (이미 데이터베이스에 있다고 가정).

---

3 (4) 레이어가있는 계층화 된 응용 프로그램을 가정 해 봅시다.

• 사용자 인터페이스 (UI)
• 비즈니스 로직 계층 (BLL)
• 데이터 액세스 계층 (DAL)
• 데이터베이스 (DB; 4 번째 계층)

이 경우 DAL은 SQL 문을 구성하고 데이터베이스에 대해 실행하여 데이터를 반환 할 책임이 있습니다.

그러한 층을 "올바르게"구성하여 항상 "선택 *"을 수행하는 유일한 방법은? 나에게 그것은 큰 사람이 아니지만 내가 왜 궁금해하는지 설명하겠습니다.

UI를 위해 적극적인 고용 기록이있는 모든 직원을 표시하기를 원한다고 가정 해 봅시다. "Active"라는 의미는 고용 기록에 오늘 날짜가 포함되어 있음을 의미합니다 (또는 아마도 사용자 인터페이스에서 설정할 수있는 날짜조차도).

이 경우, 모든 사람들에게 이메일을 보내고 싶다고 가정 해 봅시다. 그래서 BLL에 이미 같은 사람들에게 이메일을 보내지 않았는지 확인하는 코드가 있습니다.

BLL의 경우 최소한의 데이터가 필요합니다. 아마도 데이터 액세스 계층을 호출하여 활성 직원 목록을 얻은 다음 발송 된 이메일 목록을 얻기위한 전화를받습니다. 그런 다음 그것들에 합류하여 새로운 목록을 구성합니다. 아마도 이것은 데이터 액세스 계층의 도움으로 이루어질 수 있습니다. 이것은 중요하지 않습니다.

중요한 것은 비즈니스 계층의 경우 필요한 데이터가 많지 않다는 것입니다. 아마도 두 목록 모두에 대해 각 직원에 대한 고유 식별자가 필요합니다. 그런 다음 "이들은 전자 메일을 보내지 않은 활성화 된 사람들의 고유 식별자입니다"라고 말합니다. 그런 다음 비즈니스 계층에 필요한 것을 검색하는 SQL 문을 구성하는 DAL 코드를 구성합니까? 즉. 그냥 "직원들로부터 ID를 선택하십시오 ..."?

그런 다음 사용자 인터페이스를 위해 무엇을합니까? 사용자에게는 왜 이메일을 보내고 싶습니다. 예를 들어, 기초 연락처 정보 나 그들이 일하는 부서 또는 관리자 이름 등을 포함시킬 수 있습니다.

UI는 해당 데이터를 어떻게 얻습니까? 충분한 데이터를 UI로 돌려 보내도록 DAL을 변경합니까? UI에 대한 충분한 데이터를 반환하기 위해 BLL을 변경합니까? DAL에서 BLL로 돌아온 객체 또는 데이터 구조가 UI로도 전송 될 수 있다면 BLL은 많은 변경이 필요하지 않지만 UI의 요구 사항은 통신해야 할 것 이상의 레이어에 영향을 미칩니다. . 그리고 두 세계가 다른 데이터 구조에서 작동한다면, 둘 다에 대한 변경을 수행해야 할 것입니다.

그리고 UI가 변경되면, 더 많은 열을 추가함으로써 사용자를 더욱 돕기 위해 UI를 변경하려면 얼마나 깊이/가야합니까? (데이터가 이미 데이터베이스에 존재한다고 가정하므로 변경이 필요하지 않습니다.)

한 가지 제안은 Linq-to-SQL 및 IQueryable을 사용하여 DAL이 무엇을 (어떤 유형의 데이터 유형과 같이) 처리하는 경우 (클로스에서와 같이) IQueryables를 반환하는 경우 BLL이 할 수 있습니다. 잠재적으로 UI로 반환 한 다음 필요한 데이터를 검색하는 LINQ 쿼리를 구성 할 수 있습니다. 그런 다음 사용자 인터페이스 코드는 필요한 열을 가져올 수 있습니다. 이것은 iquerables와 함께 작동하기 때문에 UI는 실제로 쿼리를 실행하게 된 다음 "선택한 {x, y, z}"를 사용하여 필요한 경우 다른 테이블에 결합 할 수 있습니다.

이것은 나에게 지저분 해 보인다. UI가 LINQ 프론트 엔드 뒤에 숨겨져 있었음에도 불구하고 UI가 SQL 코드 자체를 실행합니다.

그러나 이런 일이 발생하기 위해서는 BLL 또는 DAL이 데이터베이스 연결을 닫을 수 없어야하며 IOC 유형의 세계에서는 DAL 서비스가 UI 코드가 원하는 것보다 조금 빨리 폐기 될 수 있습니다. LINQ 쿼리는 "배치 된 개체에 액세스 할 수 없다"는 예외로 끝날 수 있습니다.

그래서 저는 포인터를 찾고 있습니다. 우리는 얼마나 멀리 떨어져 있습니까? 이것을 어떻게 다루고 있습니까? 나는 UI에 대한 변경이 BLL을 통해 매우 나쁜 솔루션으로 누출 될 것이라는 사실을 고려하지만 지금은 우리가 더 잘할 수있는 것처럼 보이지 않습니다.

우리가 얼마나 어리석은 지 말해 주시고 내가 틀렸다는 것을 증명 해주세요.

그리고 이것은 레거시 시스템입니다. 데이터베이스 스키마를 변경하는 것은 아직 수년 동안 범위에 있지 않으므로 "Select *"와 동등한 ORM 객체를 사용하는 솔루션은 실제로 옵션이 아닙니다. 우리는 전체 레이어 목록을 통해 당기지 않으려는 큰 테이블이 있습니다.

Answer 1

UI 소비 사례 인보기 모델 (또는 데이터 전송 개체)의 개념을 사용하십시오. 이러한 객체를 취하는 것이 BLL의 임무가 될 것이며 데이터가 불완전한 경우 추가 데이터를 요청하십시오 (모델이라고합니다). 그런 다음 BLL은 반환 할 뷰 모델에 대한 올바른 결정을 내릴 수 있습니다. 모델 (데이터) 세부 사항이 UI에 스며 들지 않도록하십시오.

UI <-- (viewmodel) ---> BLL <-- (model) --> Peristence/Data layers

이 분리는 응용 프로그램을 더 잘 확장 할 수 있습니다. LINQ2QL 또는 다른 ORM 기술을 사용하여 View 모델의 구성 및 사양이 BLL에서 유연하게 수행 될 수 있기 때문에 지속성 독립성은 자연스럽게이 접근법에서 벗어나고 있다고 생각합니다.

Answer 2

이것은 해결하기 쉬운 문제가 아닙니다. 나는 많은 시도를 보았지만 (당신이 묘사 할 수있는 접근법을 포함하여) 완벽한 것은 없었습니다. 불행히도 우리는 여전히 완벽한 솔루션을 기다리고 있습니다. 그때까지 우리는 불완전한 일과 관련이있을 것입니다.

나는 DAL 문제가 상부 층으로 누출되어서는 안된다는 것에 전적으로 동의하므로 절연 BLL이 필요합니다.

현재 프로젝트에서 데이터 액세스 기술을 재정의하는 사치가 없어도 지속성 무지 측면에서 도메인 모델에 대해 생각하는 데 도움이됩니다. 지속성 무지의 상관 관계는 각 도메인 객체가 데이터베이스 열과 같은 것들에 대한 개념이없는 자체 포함 된 단위라는 것입니다. 데이터 integretiy를 그러한 객체에서 불변으로 시행하는 것이 가장 좋지만, 이는 인스턴스화 된 도메인 객체에 모든 구성 데이터가로드 될 것임을 의미합니다. 두 가지 제안이므로 키는 각 도메인 객체가 '적절한'양의 데이터를 유지하고로드 해야하는 좋은 도메인 모델을 찾는 것이됩니다.

너무 세분화 된 물체는 수다스러운 dal 인터페이스로 이어질 수 있지만 너무 거친 물체는 너무 많은 관련이없는 데이터가로드 될 수 있습니다.

매우 중요한 연습은 도메인 모델의 집계를 분석하고 올바르게 모델링하여 올바른 균형을 맞추는 것입니다. 그 책 도메인 구동 설계 모델링 응집체의 매우 조명 된 분석이 포함되어 있습니다.

이와 관련하여 도움이 될 수있는 또 다른 전략은 할리우드 원칙을 가능한 한 많이 적용하는 것을 목표로하는 것입니다. 당신이 설명하는 주요 문제는 쿼리에 관심이 있지만, 초점을보다 명령 지향으로 전환 할 수 있다면, 그렇지 않은 더 거친 인터페이스를 정의 할 수 있습니다. 필요하다 항상 너무 많은 데이터를로드해야합니다.

나는이 도전에 대한 간단한 해결책을 모른다. 위에서 설명한 기술과 같은 기술이 몇 가지 문제를 해결하는 데 도움이 될 수 있지만 결국에는 여전히 경험, 기술 및 징계가 필요한 예술입니다.