나에게는 꽤 어리석은 것처럼 보입니다. 나는 무엇을 얻지 않는가?DAL로 다시 라우팅하기 위해 BLL 개체에 2 개의 라이너 함수를 작성하는 것이 가치가 있습니까?
답변
내 앱이 비즈니스 레이어를 호출하여 값 목록을 선택하는 사례가 있습니다. 그런 다음 비즈니스 계층은 데이터 액세스를 수행 할 Dal을 호출합니다. 이러한 경우에는 통과를 수행하는 비즈니스 계층 방법에 대한 명백한 이유가 없지만 향후 비즈니스 논리, 데이터 처리 등을 추가 할 여지는 남습니다. 또한 앱의 연결을 끊는 데 도움이되므로 테스트가 훨씬 쉬워집니다.
그렇기 때문에 하나의 라이너를 유지해야하지만 삽입, 업데이트 등이 여전히 한두 줄이면 유효성 검사 및 비즈니스 수준 데이터 처리를 수행하는 위치를 다시 생각해야합니다.
비즈니스 로직이 BLL에 있어야합니다. BLL에 "2 라이너 기능"이 생기면 실수로 DAL 또는 UI에 비즈니스 로직을 넣었습니까?
BLL이 유효성 검사를 수행하지 않거나 비즈니스 로직을 구현하지 않고 항상 2 라이너로 남아있는 경우 그렇다면 꽤 바보입니다. 하지만 이렇게하면 비즈니스 로직 계층을 갖고 있지 않을 수도 있으며 UI에서 유효성 검사를 수행하거나 UI 또는 DAL에 비즈니스 로직을 추가했을 가능성이 큽니다. 유효성 검사가 필요없고 비즈니스 논리가없는 응용 프로그램은 거의 없습니다.
Rob와 Bullines가 더 깊은 문제를 지적해야하는 경우가 종종있는 반면, 데이터 액세스 계층으로 직행하는 것이 합당한 합법적 인 인스턴스가 있습니다. 데이터 액세스 레이어를 감싸는 두뇌없는 방법 (또는 더 나쁜 것은 전체 개체 모델)을 작성하는 것은 모든 프로그래머가 할 수있는 가장 유용한 것들 중 하나이므로 그렇게하지 마십시오. 정당한 이유가있는 경우 비즈니스 로직 계층을 거치지 않는 것이 좋다고 느낄 수 있습니다.
내가 약간 당신에게 동의하지만, 나중에 비즈니스 로직을 도입해야한다면, 애플리케이션 코드의 모든 인스턴스를 BLL을 사용하여 다시 변경해야하기 때문에 더 힘들어집니다. 처음부터 시간을 보냈다면 BLL 방법을 수정하면됩니다. –
마찬가지로 데이터가 변경되면 아무 것도하지 않는 개체 모델을 업데이트하고 유지 관리하는 데 시간을 투자 할 수 있습니다. 따라서 두 방법 중 하나를 사용하면 미래에 시간을 낭비 할 수 있습니다. 나는 한 접근법과 다른 접근법의 시대가 있다고 생각한다. –
. 소프트웨어 작성을 진지하게 생각하는 경우 단위 테스트를 위해 분리하는 것이 중요합니다. – cfeduke