현재 수용되는 엔터프라이즈 응용 프로그램 디자인 패러다임 의 장점에 대한 정직하고 사려 깊은 토론이 필요합니다 .
엔티티 객체가 존재해야한다고 확신하지 않습니다.
엔터티 객체라는 말은 “개인”, “계정”, “주문”등과 같이 응용 프로그램을 위해 구축하려는 일반적인 것을 의미합니다.
나의 현재 디자인 철학은 다음과 같습니다.
- 모든 데이터베이스 액세스는 저장 프로 시저를 통해 수행해야합니다.
- 데이터가 필요할 때마다 저장 프로 시저를 호출하고 SqlDataReader 또는 DataTable의 행을 반복합니다.
(참고 : Java EE를 사용하여 엔터프라이즈 응용 프로그램을 구축했으며 Java 사람들은 내 .NET 예제와 동등한 것을 대체하십시오)
나는 안티 -OO가 아닙니다. 엔티티가 아닌 다른 목적으로 많은 클래스를 작성합니다. 필자가 작성한 클래스의 대부분이 정적 도우미 클래스라는 것을 인정할 것입니다.
나는 장난감을 만들고 있지 않다. 여러 컴퓨터에 배포 된 대용량 트랜잭션 응용 프로그램에 대해 이야기하고 있습니다. 웹 응용 프로그램, Windows 서비스, 웹 서비스, b2b 상호 작용 등이 있습니다.
OR 매퍼를 사용했습니다. 나는 몇 가지를 썼다. Java EE 스택, CSLA 및 기타 몇 가지를 사용했습니다. 나는 그것들을 사용할뿐만 아니라 프로덕션 환경에서 이러한 응용 프로그램을 적극적으로 개발하고 유지 관리했습니다.
나는 엔티티 객체가 우리의 방법으로 받고 있는지 전투 테스트 결론에 도달 한 우리의 생활은 것 때문에 훨씬 더 쉽게 그들없이.
이 간단한 예를 고려하십시오. 응용 프로그램에서 올바르게 작동하지 않는 특정 페이지에 대한 지원 요청이있을 수 있습니다. 필드 중 하나가 그대로 유지되지 않을 수 있습니다. 내 모델에서 문제를 찾도록 지정된 개발자는 정확히 3 개의 파일을 엽니 다 . 저장 프로 시저가있는 ASPX, ASPX.CS 및 SQL 파일 저장 프로 시저 호출에 누락 된 매개 변수 일 수있는 문제는 해결하는 데 몇 분이 걸립니다. 그러나 모든 엔터티 모델을 사용하면 디버거가 항상 실행되고 코드 단계별 실행이 시작되며 Visual Studio에서 15-20 개의 파일이 열릴 수 있습니다. 스택 맨 아래로 내려갈 때 시작한 위치를 잊었습니다. 한 번에 너무 많은 것들을 머릿속에 유지할 수 있습니다. 불필요한 레이어를 추가하지 않고도 소프트웨어가 매우 복잡합니다.
개발의 복잡성과 문제 해결은 저의 한 측면 일뿐입니다.
이제 확장성에 대해 이야기하겠습니다.
개발자는 데이터베이스와 상호 작용하는 코드를 작성하거나 수정할 때마다 데이터베이스에 미치는 정확한 영향을 철저히 분석해야한다는 것을 알고 있습니까? 그리고 개발 사본뿐만 아니라 생산 모방을 의미하므로 개체에 필요한 추가 열이 현재 쿼리 계획을 무효화하고 1 초 안에 실행되는 보고서가 이제 2 분이 걸립니다. 선택 목록에 단일 열을 추가했기 때문에? 그리고 지금 필요한 색인이 너무 커서 DBA가 파일의 실제 레이아웃을 수정해야합니까?
사람들이 추상화를 통해 물리적 데이터 저장소에서 너무 멀리 떨어져 있으면 확장이 필요한 응용 프로그램으로 인해 혼란을 초래할 수 있습니다.
나는 열광자가 아닙니다. Linq에 대한 Sql, ADO.NET EF, Hibernate, Java EE 등으로의 강력한 추진력이 있기 때문에 내가 틀렸다면 확신 할 수 있습니다. 그것이 무엇인지, 왜 생각을 바꿔야하는지 알고 싶습니다.
[편집하다]
이 질문이 갑자기 다시 활성화 된 것 같습니다. 이제 몇 가지 답변에 직접 댓글을 추가 한 새로운 댓글 기능이 생겼습니다. 답장을 보내 주셔서 감사합니다. 이것이 건강한 토론이라고 생각합니다.
엔터프라이즈 응용 프로그램에 대해 이야기하고 있다는 것이 더 분명했을 것입니다. 예를 들어 누군가의 데스크톱 또는 모바일 앱에서 실행되는 게임에 대해서는 언급 할 수 없습니다.
몇 가지 유사한 답변에 대한 응답으로 내가 여기에 올려야 할 한 가지는 직교성과 우려의 분리가 종종 실체 / ORM의 근거로 인용되는 것입니다. 저에게있어 저장 절차는 제가 생각할 수있는 우려를 분리하는 가장 좋은 예입니다. 저장 프로 시저를 통하지 않고 데이터베이스에 대한 다른 모든 액세스를 허용하지 않으면 저장 프로 시저의 입력 및 출력을 유지하는 한 이론적으로 전체 데이터 모델을 다시 디자인하고 코드를 중단하지 않을 수 있습니다. 계약에 의한 프로그래밍의 완벽한 예입니다 ( “select *”를 피하고 결과 세트를 문서화하는 한).
오랫동안 업계에 종사해 왔으며 오래 지속되는 응용 프로그램을 사용해 본 사람에게 물어보십시오. 데이터베이스가 살아있는 동안 몇 개의 응용 프로그램 및 UI 계층이왔다 갔다합니까? 데이터를 얻기 위해 SQL을 생성하는 4 개 또는 5 개의 서로 다른 지속성 계층이있을 때 데이터베이스를 조정하고 리팩토링하는 것이 얼마나 어렵습니까? 당신은 아무것도 바꿀 수 없습니다! ORM 또는 SQL을 생성하는 모든 코드는 데이터베이스를 완전히 잠급니다 .
답변
응용 프로그램의 “논리적”이 얼마나 복잡한 지, 그리고 응용 프로그램을 구현 한 위치에 달려 있다고 생각합니다. 모든 논리가 저장 프로 시저에 있고 모든 응용 프로그램에서 해당 프로 시저를 호출하고 결과를 표시하는 경우 엔터티 개체 개발은 실제로 시간 낭비입니다. 그러나 객체가 서로 상호 작용하고 데이터베이스가 지속성 메커니즘 인 응용 프로그램의 경우 이러한 객체를 갖는 것이 가치가있을 수 있습니다.
그래서, 나는 하나의 크기에 맞는 대답이 없다고 말하고 싶습니다. 개발자는 때때로 너무 OO가 되려고 시도하면 해결하는 것보다 더 많은 문제가 발생할 수 있음을 알고 있어야합니다.
답변
이론에 따르면 응집력이 높고 느슨하게 결합 된 구현이 앞으로 나아갈 것이라고합니다.
그래서 나는 당신이 그 접근법, 즉 우려를 분리시키는 것에 대해 질문하고 있다고 가정합니다.
내 aspx.cs 파일이 데이터베이스와 상호 작용하고 sproc을 호출하며 IDataReader를 이해해야합니까?
팀 환경, 특히 응용 프로그램의 aspx 부분을 다루는 기술 인력이 적은 곳에서는 이러한 사람들 이이 물건을 “손질”할 필요가 없습니다.
내 도메인을 내 데이터베이스에서 분리하면 데이터베이스의 구조적 변경으로부터 나를 보호 할 수 있습니다. 데이터베이스의 효율성은 절대적으로 중요하므로, 그 분야에서 가장 뛰어난 사람은 시스템의 나머지 부분에 가능한 한 적은 영향을 미치면서 한 번에 해당 분야를 다루도록하십시오.
내가 당신의 접근 방식을 오해하지 않는 한, 데이터베이스에서 하나의 구조적 변화는 응용 프로그램의 표면에 큰 영향을 줄 수 있습니다. 이러한 우려가 분리되어 저와 우리 팀은이를 최소화 할 수 있습니다. 또한 팀의 모든 신입 사원은이 접근 방식을 더 잘 이해해야합니다.
또한 귀하의 접근 방식은 응용 프로그램의 비즈니스 논리를 데이터베이스에 상주시키는 것으로 보입니까? 이것은 나에게 잘못 느낀다. SQL은 비즈니스 로직을 표현하는 것이 아니라 데이터를 쿼리하는 데 능숙하다.
그럼에도 불구하고 흥미로운 생각은 aspx의 SQL에서 한 발짝 떨어져 있다고 생각하지만, 오래된 오래된 구조화되지 않은 ASP 시절부터는 두려움으로 가득 차 있습니다.
답변
한 가지 이유-데이터베이스 모델에서 도메인 모델을 분리합니다.
내가하는 일은 Test Driven Development를 사용하여 UI와 Model 레이어를 먼저 작성하고 Data 레이어를 조롱하여 UI와 모델이 도메인 특정 객체를 중심으로 빌드 한 다음 나중에이 객체를 내가 사용중인 기술에 매핑하는 것입니다. 데이터 레이어. 데이터베이스 구조가 응용 프로그램의 디자인을 결정하게하는 것은 나쁜 생각입니다. 가능하면 먼저 앱을 작성하고 다른 방식이 아닌 데이터베이스 구조에 영향을 미치도록하십시오.
답변
나에게 그것은 응용 프로그램이 데이터 저장 방법에 관심을 갖기를 원하지 않기로 요약합니다. 아마이 말을 할 수있을 것입니다 …하지만 응용 프로그램은 데이터가 아니며 데이터는 응용 프로그램의 인공물입니다. 내 응용 프로그램이 DataSets, DataTables 및 DataRows와 같은 기술이 아닌 고객, 주문 및 항목의 관점에서 생각하기를 원합니다.
나는 항상 일정한 양의 커플 링이 있다는 것에 동의하지만, 커플 링은 아래쪽보다는 오히려 위쪽에 도달하는 것이 좋습니다. 나는 나무의 가지와 잎을 줄기를 바꾸는 것보다 쉽게 조정할 수 있습니다.
쿼리가 응용 프로그램의 일반 데이터 액세스보다 약간 나 빠지기 때문에보고를 위해 sproc을 예약하는 경향이 있습니다.
나는 또한 하나의 열이 지속되지 않는 것이 문제가되지 않을 것이라는 시나리오와 같은 시나리오에서 초기에 적절한 단위 테스트로 생각하는 경향이 있습니다.
답변
에릭, 넌 죽었어 실제로 확장 가능하고 쉽게 유지 관리 할 수 있고 강력한 응용 프로그램의 경우 유일한 해결책은 모든 쓰레기를 없애고 기본 사항을 고수하는 것입니다.
나는 내 경력과 비슷한 궤적을 따랐으며 같은 결론에 도달했다. 물론, 우리는 이단자로 여겨지고 재미있었습니다. 그러나 내 물건은 잘 작동합니다.
모든 코드 줄은 의심스럽게 봐야합니다.
답변
제안한 것과 비슷한 예를 들어 대답하고 싶습니다.
회사에서는 제품에 대한 간단한 CRUD 섹션을 작성해야했고 모든 엔티티와 별도의 DAL을 작성했습니다. 나중에 다른 개발자가 관련 테이블을 변경해야했으며 여러 필드의 이름을 바꿨습니다. 양식을 업데이트하기 위해 변경해야하는 유일한 파일은 해당 테이블의 DAL이었습니다.
엔티티가 프로젝트에 가져 오는 것은 다음과 같습니다.
직교성 : 한 계층의 변경 사항은 다른 계층에 영향을 미치지 않을 수 있습니다 (물론 데이터베이스를 크게 변경하면 모든 계층에 영향을 주지만 대부분의 작은 변경 사항은 적용되지 않습니다).
테스트 가능성 : 데이터베이스를 건드리지 않고도 로직을 테스트 할 수 있습니다. 이렇게하면 테스트 성능이 향상됩니다 (더 자주 실행할 수 있음).
우려의 분리 : 큰 제품에서는 데이터베이스를 DBA에 할당 할 수 있으며 데이터베이스에서 지옥을 최적화 할 수 있습니다. 설계에 필요한 지식이있는 비즈니스 전문가에게 모델을 지정하십시오. 웹 양식 등에서 더 경험이 많은 개발자에게 개별 양식을 할당하십시오.
마지막으로 대부분의 ORM 맵퍼가 저장 프로 시저를 지원한다고 덧붙이고 싶습니다.
건배.
답변
나는 당신이이 주제에 대해“당신이 씹을 수있는 것보다 더 많은 것을 물지”고 있다고 생각합니다. Ted Neward는 ” 컴퓨터 과학의 베트남 “이라고 불렀을 때 플립 팬츠가 아니 었습니다 .
내가 당신을 절대적으로 보장 할 수있는 한 가지는 무수히 많은 다른 블로그, 포럼, 팟 캐스트 등에서 자주 입증 된 것처럼 문제에 대한 아무도의 견해를 바꿀 수 없다는 것입니다.
논란의 여지가있는 주제에 대해 공개적인 토론과 토론을하는 것은 확실히 괜찮습니다. 두 가지 측면이 모두 동의하지 않고 소프트웨어 작성에 착수 한 것은 너무나 많은 일입니다.
양쪽에 대해 더 자세히 읽으려면 Ted의 블로그, Ayende Rahein, Jimmy Nilson, Scott Bellware, Alt.Net, Stephen Forte, Eric Evans 등의 기사를 참조하십시오.
