엔티티 객체가 필요한 이유는 무엇입니까? [닫은]

현재 수용되는 엔터프라이즈 응용 프로그램 디자인 패러다임 의 장점에 대한 정직하고 사려 깊은 토론이 필요합니다 .

엔티티 객체가 존재해야한다고 확신하지 않습니다.

엔터티 객체라는 말은 "개인", "계정", "주문"등과 같이 응용 프로그램을 위해 구축하려는 일반적인 것을 의미합니다.

나의 현재 디자인 철학은 다음과 같습니다.

• 모든 데이터베이스 액세스는 저장 프로 시저를 통해 수행해야합니다.
• 데이터가 필요할 때마다 저장 프로 시저를 호출하고 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 등의 기사를 참조하십시오.

@Dan, 죄송합니다. 제가 찾는 것은 아닙니다. 나는 이론을 안다. 당신의 진술은 "아주 나쁜 생각이다"는 실제 사례에 의해 뒷받침되지 않습니다. 우리는 적은 시간, 적은 인원, 적은 실수로 소프트웨어를 개발하려고 노력하고 있으며 쉽게 변경할 수있는 기능을 원합니다. 내 경험상, 귀하의 다층 모델은 위의 모든 범주에서 부정적입니다. 특히 데이터 모델을 마지막으로 만드는 것과 관련하여. 물리적 데이터 모델은 1 일부터 중요한 고려 사항이어야합니다.

귀하의 질문이 정말 흥미로 웠습니다.
일반적으로 응용 프로그램의 비즈니스 논리를 캡슐화하려면 엔터티 개체가 필요합니다. 이 논리를 데이터 계층에 적용하는 것은 실제로 복잡하고 부적절합니다.
이러한 개체 개체를 피하기 위해 무엇을 하시겠습니까? 어떤 솔루션을 염두에두고 있습니까?

엔터티 개체는 응용 프로그램 계층에서 캐시를 용이하게 할 수 있습니다. 데이터 리더를 캐싱하는 것이 좋습니다.

또한 실체가 무엇인지에 대한 개념에 대해서도 이야기해야합니다. 이 토론을 읽으면 대부분의 사람들이 빈혈 도메인 모델 의 의미에서 엔티티를보고 있다는 인상을받습니다 . 많은 사람들이 Anemic Domain Model을 반 패턴으로 고려하고 있습니다!

리치 도메인 모델에는 가치가 있습니다. 이것이 바로 도메인 기반 디자인의 핵심 입니다. 저는 개인적으로 OO가 복잡성을 극복하는 방법이라고 믿습니다. 이는 데이터 액세스, UI 바인딩, 보안과 같은 기술적 복잡성 뿐만 아니라 비즈니스 영역의 복잡성도 의미합니다 !

비즈니스 문제 를 분석, 모델링, 설계 및 구현 하기 위해 OO 기술을 적용 할 수 있다면 이는 사소한 응용 프로그램의 유지 관리 및 확장성에있어 엄청난 이점입니다!

엔터티와 테이블간에 차이가 있습니다. 엔티티는 모델을 나타내야하며 테이블은 모델의 데이터 측면을 나타냅니다!

데이터는 앱보다 수명이 길지만 David Laribee의 인용문 을 고려 하십시오 . 모델은 영원히 ... 데이터는 행복한 부작용입니다.

이 주제에 대한 더 많은 링크 :

• 세터와 게터가 악한 이유

• 순수한 OO의 반환

• 포조 vs. 노조

• 슈퍼 모델 2 부

• TDD, Mocks 및 디자인

정말 흥미로운 질문입니다. 솔직히 나는 왜 실체가 좋은지를 증명할 수 없다. 그러나 내가 왜 그들을 좋아하는지 의견을 공유 할 수 있습니다. 같은 코드

void exportOrder(Order order, String fileName){...};

DataRow를 가져 와서 예상되는 열과 필요한 유형을 문서화하는 대신 DB에서, 웹 요청, 단위 테스트 등에서 주문이 어디서 왔는지 걱정하지 않습니다. 있다. 저장 프로 시저로 구현 한 경우에도 동일하게 적용됩니다. 레코드 ID를 여전히 푸시해야하지만 DB에는 없어야합니다.

이 방법의 구현은 DB에 정확히 표시되는 방법이 아니라 주문 추상화를 기반으로 수행됩니다. 내가 구현 한 이러한 작업의 대부분은 실제로이 데이터가 저장되는 방법에 의존하지 않습니다. 일부 작업에는 성능과 확장 성을 위해 DB 구조와의 연결이 필요하다는 것을 이해합니다. 내 경험으로는 너무 많지 않습니다. 내 경험상 Person이 String을 반환하는 .getFirstName ()과 Address를 반환하는 .getAddress ()를 가지고 있고 address가 .getZipCode () 등을 가지고 있다는 것을 알고 충분합니다. .

추가 열이 보고서 성능을보고 할 때와 같이 설명 된대로 이러한 문제를 처리해야하는 경우 작업의 경우 DB가 중요한 부분이므로 실제로 가능한 한 가까이 있어야합니다. 엔티티는 편리한 추상화를 제공 할 수 있지만 중요한 세부 사항도 숨길 수 있습니다.

확장 성은 흥미로운 점입니다. 페이스 북, 라이브 저널, 플리커와 같이 엄청난 확장 성을 필요로하는 대부분의 웹 사이트는 DB를 최대한 드물게 사용하고 캐싱, 특히 RAM 사용으로 확장 성 문제를 해결할 때 DB-ascetic 방식을 사용하는 경향이 있습니다. http://highscalability.com/ 에 흥미로운 기사가 ​​있습니다.

추상화 및 느슨한 결합 외에도 엔티티 객체에 대한 다른 좋은 이유가 있습니다. 내가 가장 좋아하는 것 중 하나는 DataReader 또는 DataTable로는 얻을 수없는 강력한 타이핑입니다. 또 다른 이유는 잘 수행되면 적절한 엔티티 클래스가 코드를 보는 사람이 필드 이름이있는 문자열이 아닌 이해할 수있는 도메인 특정 용어에 대해 일류 구문을 사용하여 코드를 더 지속 가능하게 만들 수 있다는 것입니다 DataRow를 인덱싱합니다. 많은 매핑 프레임 워크가 sproc에 매핑 할 수 있기 때문에 저장 프로시 저는 실제로 ORM 사용과 직교합니다.

나는 sprocs + datareaders가 좋은 ORM을 대신한다고 생각하지 않습니다. 저장 프로 시저를 사용하면 호출 코드와 다른 형식 시스템을 사용하는 프로 시저의 형식 서명에 여전히 구속되어 있고 밀접하게 연결되어 있습니다. 저장 프로시 저는 추가 옵션 및 스키마 변경을 수용하기 위해 수정 될 수 있습니다. 스키마가 변경 될 경우 저장 프로 시저의 대안은 뷰를 사용하는 것입니다. 개체를 뷰에 매핑 한 다음 변경시 기본 테이블에 뷰를 다시 매핑 할 수 있습니다.

귀하의 경험이 주로 Java EE 및 CSLA로 구성되어 있다면 ORM에 대한 혐오감을 이해할 수 있습니다. 매우 가벼운 프레임 워크이며 주로 데이터베이스 테이블과의 일대일 맵핑 인 LINQ to SQL을 살펴보고 싶을 수 있지만 일반적으로 완전한 비즈니스 오브젝트가 되려면 약간의 확장 만 필요합니다. LINQ to SQL은 입력 및 출력 개체를 저장 프로 시저의 매개 변수 및 결과에 매핑 할 수도 있습니다.

ADO.NET 엔터티 프레임 워크는 데이터베이스 테이블을 서로 상속하는 엔터티 클래스 또는 단일 엔터티로 집계 된 여러 테이블의 열로 볼 수 있다는 추가 이점이 있습니다. 스키마를 변경해야하는 경우 실제 애플리케이션 코드를 변경하지 않고 개념 모델에서 스토리지 스키마로의 맵핑을 변경할 수 있습니다. 그리고 다시 저장 프로 시저를 사용할 수 있습니다.

코드의 유지 관리가 불가능하거나 개발자의 생산성 (예 : sproc-writing과 app-writing 사이의 컨텍스트 전환으로 인해 발생할 수 있음)이 애플리케이션의 확장 성 문제로 인해 기업의 IT 프로젝트가 더 많이 실패한다고 생각합니다.

또한 두 모델을 분리하면 응용 프로그램을 다른 데이터베이스 서버 또는 데이터베이스 모델에서 실행할 수 있다는 Dan의 답변 에 추가하고 싶습니다 .

둘 이상의 웹 서버를로드 밸런싱하여 앱을 확장해야하는 경우 어떻게해야합니까? 모든 웹 서버에 전체 앱을 설치할 수 있지만 더 나은 솔루션은 웹 서버가 응용 프로그램 서버와 통신하도록하는 것입니다.

그러나 엔터티 개체가 없으면 이야기 할 것이 많지 않습니다.

단순하고 내부적이며 짧은 수명의 응용 프로그램이라면 모놀리스를 작성해서는 안된다는 말은 아닙니다. 그러나 적당히 복잡해 지거나 상당한 시간이 걸리면 좋은 디자인을 생각해야합니다.

이를 통해 유지 관리에 소요되는 시간을 절약 할 수 있습니다.

응용 프로그램 논리를 프레젠테이션 논리와 데이터 액세스에서 분리하고 DTO를 전달하여 분리합니다. 독립적으로 변경할 수 있습니다.

comp.object 에서이 게시물을 찾을 수 있습니다 .

나는 동의하거나 동의하지 않는다고 주장하지는 않지만 흥미롭고이 주제와 관련이 있다고 생각합니다.

질문 : 모든 비즈니스 로직이 데이터베이스에 갇힌 경우 연결이 끊어진 응용 프로그램을 어떻게 처리합니까?

관심있는 엔터프라이즈 응용 프로그램 유형에서는 여러 사이트를 처리해야하며 일부 사이트는 연결이 끊긴 상태에서 작동 할 수 있어야합니다.
비즈니스 로직이 다양한 애플리케이션 유형에 통합하기 쉬운 도메인 계층에 캡슐화 된 dll경우 (예 : 비즈니스 규칙을 인식하고 필요한 경우 로컬로 적용 할 수있는) 애플리케이션을 빌드 할 수 있습니다.

도메인 계층을 데이터베이스의 저장 프로 시저에 유지하려면 데이터베이스에 대한 영구적 인 가시선이 필요한 단일 유형의 응용 프로그램을 사용해야합니다.

특정 클래스의 환경에서는 괜찮지 만 엔터프라이즈 응용 프로그램 의 전체 범위를 다루지는 않습니다 .

@jdecuyper, 내가 자주 반복하는 최대 한 가지는 "비즈니스 로직이 데이터베이스에 없으면 권장 사항 일뿐"입니다. 폴 닐슨 (Paul Nielson)은 그의 책 중 하나에서 그렇게 말했다. 응용 프로그램 계층과 UI가왔다 갔다하더라도 데이터는 일반적으로 매우 오래 지속됩니다.

엔터티 개체를 어떻게 피합니까? 저장 프로시 저는 대부분 또한 비즈니스 로직이 원하는지 여부에 관계없이 애플리케이션의 모든 계층을 통해 도달하는 경향이 있음을 자유롭게 인정합니다. 일정량의 커플 링은 고유하며 불가피합니다.

나는 최근에이 일에 대해 많이 생각하고있다. 나는 CSLA를 한동안 많이 사용했으며 "모든 비즈니스 로직 (또는 적어도 합리적으로 가능한 한)이 비즈니스 엔터티에 캡슐화되어있다"고 말하는 순 결함을 좋아합니다.

비즈니스 엔터티 모델이 데이터베이스 디자인이 데이터 작업 방식과 다른 경우 (많은 비즈니스 소프트웨어의 경우)에 많은 가치를 제공하는 것을 보았습니다.

예를 들어, "고객"이라는 아이디어는 고객이 주문한 모든 주문과 모든 고객의 직원 및 연락처 정보 및 일부 속성과 결합 된 고객 테이블의 기본 레코드로 구성 될 수 있습니다. 룩업 테이블에서 고객과 그 하위 항목을 확인할 수 있습니다. 비즈니스 관점에서 고객 개념에 이러한 모든 사항이 포함되어 있고 데이터베이스에서 관계가 적용되거나 적용되지 않을 수 있기 때문에 개발 관점에서 고객과 단일 엔티티로 작업 할 수있는 것이 정말 좋습니다.

"비즈니스 규칙이 데이터베이스에 없으면 제안 일뿐"이라는 인용문에 감사하지만, 비즈니스 규칙을 적용하기 위해 데이터베이스를 디자인해서는 안되며 효율적이고 빠르며 정규화되도록 디자인해야한다고 생각합니다. .

즉, 다른 사람들이 위에서 언급했듯이 "완벽한 디자인"은 없으며 공구가 작업에 적합해야합니다. 그러나 비즈니스 엔터티를 사용하면 비즈니스 논리를 어디로 수정해야하는지 알기 때문에 유지 관리 및 생산성에 실제로 도움이 될 수 있으며 개체는 실제 개념을 직관적 인 방식으로 모델링 할 수 있습니다.

에릭,

아무도 당신이 원하는 프레임 워크 / 접근 방식을 선택하는 것을 막을 수 없습니다. "데이터 기반 / 저장 프로 시저 기반"경로로 이동하려는 경우 반드시 진행하십시오! 특히, 실제로 그렇다면, 애플리케이션을 적시에 정시에 제공 할 수 있습니다.

주의 사항 (질문의 단점), 모든 비즈니스 규칙은 저장 프로 시저에 있어야하며 응용 프로그램은 씬 클라이언트에 지나지 않습니다.

즉, OOP에서 응용 프로그램을 수행하는 경우 동일한 규칙이 적용됩니다. OOP의 원칙을 따르고 여기에는 도메인 모델을 나타내는 엔터티 개체 만들기 가 포함됩니다.

여기서 유일한 실제 규칙은 단어 일관성 입니다. 아무도 당신이 DB 중심으로가는 것을 막지 않습니다. 구식 구조화 (일명 기능적 / 절차 적) 프로그램을하는 것을 막는 사람은 없습니다. 아무도 COBOL 스타일 코드를 수행하는 것을 막는 사람이 없습니다. 그러나 어느 정도의 성공을 거두려면 애플리케이션이이 경로를 따라 가면 매우 일관성이 있어야합니다.

"Enterprise Applications"를 어떻게 생각하는지 잘 모르겠습니다. 그러나 RDBMS가 정식으로 설정되어 내부 또는 외부의 다른 시스템과 시스템을 상호 운용 할 필요가없는 내부 응용 프로그램으로 정의하고 있다는 인상을 받았습니다.

그러나 기본 CRUD 작업에 대해서만 각 테이블에 대해 4 개의 저장 프로 시저에 해당하는 100 개의 테이블이있는 데이터베이스가있는 경우 400 개의 저장 프로시 저는 유지 관리가 필요하고 형식이 엄격하지 않아 오타에 취약하거나 단위 테스트를 수행 할 수 없습니다. . 오픈 소스 전도자이며 RDBMS를 SQL Server에서 MySql로 변경하려는 새 CTO를 받으면 어떻게됩니까?

오늘날 엔터프라이즈 응용 프로그램 또는 제품이 SOA를 사용하고 있고 웹 서비스를 노출하기위한 몇 가지 요구 사항이 있습니다. 접근 방식을 사용하면 Serialized DataTable 또는 DataRows가 노출됩니다. 이제 클라이언트가 .NET이고 내부 네트워크에 있다고 보장되는 경우 이는 허용 가능한 것으로 간주 될 수 있습니다. 그러나 클라이언트를 알 수없는 경우 직관적이고 대부분의 경우 전체 데이터베이스 스키마를 노출하지 않으려는 API를 설계하려고 노력해야합니다. 필자는 Java 개발자에게 DataTable이 무엇이며 어떻게 사용하는지 설명하고 싶지 않습니다. 또한 Bandwith 및 페이로드 크기와 직렬화 된 DataTable을 고려해야하며 DataSet은 매우 무겁습니다.

소프트웨어 디자인의 은색 총알은 없으며 실제로 우선 순위가 어디에 있는지에 달려 있습니다. 나에게 그것은 단위 테스트 가능 코드와 쉽게 사용할 수있는 느슨하게 결합 된 구성 요소에 있습니다.

내 2 센트 만

OO와 RDB 사이의 거리 문제에 대한 또 다른 각도를 제공하고 싶습니다 : 역사.

모든 소프트웨어에는 현실의 추상화 모델 인 현실 모델이 있습니다. 컴퓨터 프로그램은 현실의 모든 복잡성을 포착 할 수 없으며 프로그램은 현실의 일련의 문제를 해결하기 위해 작성되었습니다. 따라서 모든 소프트웨어 모델은 현실의 축소입니다. 때로는 소프트웨어 모델이 현실을 스스로 축소시킵니다. 자동차가 파란색이고 합금이있는 한 렌터카 회사가 자동차를 예약하고 싶을 때와 마찬가지로, 귀하의 요청이 컴퓨터에 맞지 않기 때문에 운영자는 준수 할 수 없습니다.

RDB는 회계라는 테이블에 정보를 넣는 매우 오래된 전통에서 비롯되었습니다. 종이, 펀치 카드, 컴퓨터에서 회계를 수행했습니다. 그러나 회계는 이미 현실의 축소입니다. 회계는 사람들로 하여금 시스템이 현실이 될 정도로 오랫동안 시스템을 따르도록 강요했습니다. 그렇기 때문에 회계 용 컴퓨터 소프트웨어를 만드는 것이 비교적 쉬운 이유입니다. 회계는 컴퓨터가 등장하기 훨씬 전에 정보 모델을 가지고있었습니다.

우수한 회계 시스템의 중요성과 모든 비즈니스 관리자로부터받는 승인을 고려할 때 이러한 시스템은 매우 발전했습니다. 데이터베이스 기반은 이제 매우 견고하고 중요한 데이터에 중요한 데이터를 유지하는 데 주저하지 않습니다.

사람들이 현실의 다른 측면이 회계 (이미 모델 임)보다 모델링하기가 어렵다는 것을 알게되었을 때 OO가 반드시 필요하다고 생각합니다. OO는 매우 성공적인 아이디어가되었지만 OO 데이터의 지속성은 상대적으로 저개발되었습니다. RDB / Accounting은 쉬운 승리를 거두었지만 OO는 훨씬 더 큰 분야 (기본적으로 회계가 아닌 모든 것)입니다.

우리 중 많은 사람들이 OO를 사용하고 싶었지만 데이터의 안전한 저장을 원합니다. 존경받는 회계 시스템과 동일한 방식으로 데이터를 저장하는 것보다 더 안전한 것은 무엇입니까? 그것은 유망한 전망이지만 우리 모두 같은 함정에 빠지게됩니다. 회계의 전통과 입장의 혜택을 얻은 RDB 산업의 막대한 노력과 비교할 때 OO 지속성을 생각하는 데 어려움을 겪은 사람은 거의 없습니다.

Prevayler와 db4o는 몇 가지 제안입니다. 내가 들어 본 적이없는 다른 것들이 있다고 확신하지만 최대 절전 모드와 같은 언론의 절반은 얻지 못했습니다.

오래된 파일에 객체를 저장하는 것은 다중 사용자 응용 프로그램, 특히 웹 응용 프로그램에서 심각하게 고려되지 않는 것처럼 보입니다.

OO와 RDB 사이의 틈새를 막으려는 일상에서 나는 OO를 최대한 사용하지만 상속을 최소화하려고 노력합니다. 나는 종종 SP를 사용하지 않습니다. 회계와 같은 측면에서만 고급 검색어를 사용합니다.

틈이 잘 풀리면 기쁘다. 오라클이 "Oracle Object Instance Base"와 같은 것을 시작하면 솔루션이 나올 것이라고 생각합니다. 실제로 따라 잡기 위해서는 안심할 수있는 이름이 있어야합니다.

지금은 시간이 많지 않지만 내 머리 꼭대기에서 ...

엔터티 모델을 사용하면 저장 프로 시저 인터페이스가 할 수있는 것 이상으로 데이터베이스 및 기타 가능한 시스템에 일관된 인터페이스를 제공 할 수 있습니다. 전사적 비즈니스 모델을 사용하면 모든 애플리케이션이 데이터에 일관되게 영향을 미치도록 할 수 있습니다. 이는 매우 중요한 일입니다. 그렇지 않으면 나쁜 데이터로 끝나게됩니다.

응용 프로그램이 하나 뿐인 경우 해당 응용 프로그램이나 데이터의 크기에 관계없이 실제로 "엔터프라이즈"시스템이 없습니다. 이 경우 말한 것과 비슷한 접근 방식을 사용할 수 있습니다. 미래에 시스템을 확장하기로 결정한 경우 필요한 작업에 유의하십시오.

다음은 명심해야 할 몇 가지 사항입니다 (IMO).

1. 생성 된 SQL 코드가 잘못되었습니다 (예외 사항 제외). 죄송합니다. 많은 사람들이 시간을 절약 할 수 있다고 생각하지만, 제가 작성할 수있는 것보다 더 효율적인 코드를 생성 할 수있는 시스템을 찾지 못했으며 종종 코드가 너무 끔찍합니다. 또한 종종 사용되지 않는 많은 SQL 코드를 생성하게됩니다. 룩업 테이블과 같은 매우 간단한 패턴은 예외입니다. 그래도 많은 사람들이 쫓겨납니다.
2. 엔티티 <> 테이블 (또는 논리적 데이터 모델 엔티티) 데이터 모델에는 종종 테이블 행이 서로 관련되는 방식 또는 선언적 RI에 비해 너무 복잡한 다른 유사한 규칙에 대한 규칙을 포함 할 수있는 데이터베이스에 최대한 밀접하게 적용해야하는 데이터 규칙이 있습니다. 이들은 저장 프로 시저에서 처리해야합니다. 모든 스토어드 프로 시저가 간단한 CRUD 프로세스 인 경우이를 수행 할 수 없습니다. 또한 CRUD 모델은 일반적으로 네트워크에서 데이터베이스로의 왕복을 최소화하지 않기 때문에 성능 문제가 발생합니다. 이는 종종 엔터프라이즈 응용 프로그램에서 가장 큰 병목 현상입니다.

때로는 응용 프로그램과 데이터 계층이 밀접하게 연결되어 있지 않습니다. 예를 들어 전화 요금 청구 응용 프로그램이있을 수 있습니다. 나중에 전화 사용을 모니터링하여 a)보다 나은 광고를 제공하기 위해 b) 전화 요금제를 최적화하는 별도의 응용 프로그램을 만듭니다.

이러한 응용 프로그램은 서로 다른 관심사 및 데이터 요구 사항을 갖지만 (데이터가 동일한 데이터베이스에서 나오는 경우에도) 서로 다른 디자인을 이끌어냅니다. 코드베이스는 응용 프로그램 중 하나에서 절대 엉망이 될 수 있으며 데이터베이스가 코드를 구동하게하면 유지해야 할 악몽이 될 수 있습니다.

도메인 논리가 데이터 스토리지 논리와 분리되어있는 응용 프로그램은 모든 종류의 데이터 소스 (데이터베이스 또는 기타) 또는 UI (웹 또는 Windows (또는 Linux 등)) 응용 프로그램에 적용 할 수 있습니다.

데이터베이스에 거의 갇혀 있습니다. 현재 데이터베이스 시스템에 만족하는 회사와 사용하는 경우 나쁘지 않습니다. 그러나 데이터베이스는 시간이 지남에 따라 발전하므로 회사에서 사용하기에 정말 새롭고 새로운 데이터베이스 시스템이있을 수 있습니다. 서비스 지향 아키텍처와 같은 웹 서비스 방식의 데이터 액세스 방식으로 전환하려는 경우 어떻게해야합니까? 저장 프로 시저를 모든 곳으로 포팅해야 할 수도 있습니다.

또한 도메인 로직은 UI를 추상화합니다. UI가 진화하는 대형 복잡한 시스템 (특히, 더 많은 고객을 지속적으로 검색하는 경우)에서 더 중요 할 수 있습니다.

또한 저장 프로 시저 대 도메인 논리에 대한 결정적인 대답이 없다는 것에 동의합니다. 나는 정교한 논리 절차보다 정교한 저장 프로 시저를 유지 관리하기가 어렵다고 생각하기 때문에 도메인 논리 캠프에 있습니다. 그러나 그것은 완전히 다른 논쟁입니다

특정 종류의 응용 프로그램을 작성하고 특정 종류의 문제를 해결하는 데 익숙하다고 생각합니다. "데이터베이스 우선"관점에서이를 공격하는 것 같습니다. 데이터가 DB에 유지되는 곳에는 많은 개발자가 있지만 성능이 최우선 순위가 아닙니다. 대부분의 경우 지속성 계층에 추상화를 적용하면 코드가 크게 단순화되고 성능 비용은 문제가되지 않습니다.

무엇을하든 OOP가 아닙니다. 그것은 틀린 것이 아니며 단지 OOP가 아니며, 모든 othe 문제에 솔루션을 적용하는 것은 합리적이지 않습니다.

흥미로운 질문입니다. 몇 가지 생각 :

1. 모든 비즈니스 로직이 데이터베이스에 있는지 어떻게 단위 테스트를 하시겠습니까?
2. 데이터베이스 구조, 특히 앱의 여러 페이지에 영향을 미치는 변경 사항이 앱 전체에서 변경해야하는 번거 로움이 아닐까요?

좋은 질문!

내가 좋아하는 한 가지 방법은 특정 컨텍스트와 관련된 객체 인스턴스를 생성하는 반복자 / 생성기 객체를 만드는 것입니다. 일반적 으로이 객체는 기본 데이터베이스 액세스 항목을 래핑하지만 사용할 때 알 필요는 없습니다.

예를 들어

AnswerIterator 객체는 AnswerIterator.Answer 객체를 생성합니다. 후드 아래에서 모든 답변을 가져 오기 위해 SQL 문을 반복하고 모든 관련 주석을 가져 오기 위해 다른 SQL 문을 반복합니다. 그러나 반복자를 사용할 때이 컨텍스트에 대한 최소 속성이있는 Answer 객체를 사용합니다. 약간의 스켈레톤 코드를 사용하면 거의 사소한 일이됩니다.

나는 작업 할 거대한 데이터 세트가있을 때 이것이 잘 작동한다는 것을 알았으며 올바르게 수행하면 비교적 테스트하기 쉬운 작고 일시적인 객체를 제공합니다.

기본적으로 데이터베이스 액세스에 대한 얇은 비니어이지만 필자가 필요할 때 추상화하는 유연성을 여전히 제공합니다.

내 응용 프로그램의 객체는 데이터베이스와 일대일로 연결되는 경향이 있지만 sprocs 대신 Linq To Sql을 사용하면 복잡한 쿼리를 작성하는 것이 훨씬 쉽습니다. 특히 지연된 실행을 사용하여 빌드 할 수 있습니다. 예를 들어 Images.User.Ratings의 r 등에서 SQL에서 여러 조인 문을 해결하려고 시도하지 않고 페이징에 대해 Skip & Take를 사용하면 row_number & 'over'코드를 포함하지 않고 코드를 단순화 할 수 있습니다.

엔티티 객체에서 멈추는 이유는 무엇입니까? 엔터프라이즈 레벨 앱에서 엔티티 오브젝트의 값이 표시되지 않으면 순수한 기능 / 절차 언어로 데이터 액세스를 수행하여 UI에 연결하십시오. 왜 모든 OO "fluff"를 잘라 내지 않겠습니까?