2009-05-05 5 views
2

저는 초보자입니다. 데이터베이스 응용 프로그램을 만드는 데 어려움을 겪었을 때 저는 항상 양식을 만들고 거기에 모든 코드와 바인딩을 넣었습니다. 정보를 보유하고있는 배열과 목록을 가지는 대신 데이터베이스에 직접 변경을가했습니다.데이터 기반 응용 프로그램의 "엔터티"를 처리하는 클래스를 만드십니까?

이제는 고객에게 위젯을 판매하고 데이터베이스에 판매 정보를 보관한다고 가정 해 보았습니다. 데이터베이스에 액세스하기위한 프로그램을 작성했다면 해당 엔터티와 작업 할 '고객'및 '위젯'유형의 클래스를 만들고 싶지 않습니까?

내가 잘못 생각한다면 데이터베이스 응용 프로그램을 프로그래밍하는 데 적합한 방법은 무엇일까요?

답변

4

예.

n-tier 프로그래밍을 살펴보고 싶습니다.

기본적으로 프런트 엔드 (프레젠테이션 계층)는 클래스 라이브러리 (비즈니스 계층)에만 액세스 할 수 있습니다. 그런 다음 클래스 라이브러리가 데이터베이스에 액세스합니다.

이렇게하면 긴밀하게 결합 된 솔루션이 아니며 유지 관리가 용이 ​​한 코드를 사용할 수 있습니다. 또한 계층을 도입함으로써 비즈니스 계층과의 인터페이스를 변경할 필요가없는 한 프론트 엔드의 코드를 다시 작성할 필요없이 DB를 변경할 수 있습니다.

바인딩과 관련하여 Visual Studio Windows Forms (2005 이후)를 사용하는 경우 bindingSource을 사용하여 컨트롤을 바인딩 할 수 있습니다. ASP.NET을 사용하는 경우 컨트롤은 아무 문제없이 개체 목록에 바인딩해야합니다.

ASP.Net의 경우 ObjectDataSource을 살펴볼 가치가 있습니다. 나는 그것을 직접 사용하지 않았지만 웹상에 많은 샘플이있다. here 또는 here을 시도해보십시오.

+0

그렇다면 Visual Studio 및 .NET에서 바인딩 및 기타 데이터 기능은 무엇입니까? "데이터 액세스"레이어를 사용하여 프레젠테이션 레이어에 데이터를 제공하는 경우 데이터 액세스 레이어에서 처음부터 대부분의 코드를 작성하지 않겠습니까? – Pete

+1

사용하지 마십시오. .NET 도입 전부터 도입 된 이래로 저는 기본 데이터베이스에 직접 바인딩하는 프런트 엔드 컨트롤을 Evil이라고 항상 생각했습니다. 그냥 내 의견을, 물론 .... – RolandTumble

+0

좋아, 그래서 처음부터 데이터베이스와 클래스의 필드를 채우기 위해 내 데이터베이스 클래스를 사용하는 고객을위한 다른 클래스를 작성하고 싶습니다? 이것은 폼에 텍스트 상자와 레이블을 던지고 컨트롤을 바인딩하는 것보다 선호됩니까? – Pete

2

예.

Object-Relational Mapping을 자세히보고 싶습니다.

실제 비즈니스 엔티티는 관계형 테이블에 맵핑되는 오브젝트로 모델링됩니다.

+1

신중하게 말하십시오. "지도"가 "반영"을 의미하지 않는다는 것을 설명하는 것이 가치가있을 수 있습니다. – dkretz

1

프리젠 테이션 계층이 데이터베이스 구조에 직접 종속되지 않도록하려는 경우. 문제는 데이터베이스 구조가 변경되고 프리젠 테이션 계층이 변경되어야하며 장기적으로 문제를 발생시키는 경향이있는 경우입니다. 또한 프리젠 테이션 계층이 데이터베이스와 직접 상호 작용하는 것과 관련된 보안 문제가 있습니다.

여기에 대략적인 비유는 시장입니다. 빵 한 덩어리를 사러 가게에 갈 때 밀을 어떻게 자라는 지 알 필요가 없습니다. 당신이 알아야 할 것은 돈이 있고, 빵을 가지고 있으며, 일정 금액의 빵을 일정량 교환한다는 것입니다. 밀을 심는 데 걸리는 시간이나 짚을 제거하는 방법 등을 알 필요가 없습니다. 왜냐하면 보강층이 당신을 위해 그것을 돌봐주기 때문입니다. 마찬가지로 농부는 빵을 어떻게 사람들 한테 팔고, 빵을 만드는 방법까지 알 필요가 없다. 그가해야 할 일은 밀을 재배하는 법을 아는 것입니다.

중간 계층을 사용하여 프리젠 테이션 계층과 데이터베이스 계층 간의 상호 작용을 권장합니다. 이것이 비즈니스 논리를 두는 곳입니다. 예를 들어 사이트에서 위젯을 판매한다고 가정 해 보겠습니다. 프리젠 테이션 코드에서 데이터베이스에 위젯을 쿼리하고 표시하는 대신 위젯을 처리하는 비즈니스 객체가 있습니다.이런 식으로 비즈니스 오브젝트는 데이터베이스 구조가 무엇인지 알아야하지만 프리젠 테이션 계층은 표시 할 위젯 목록을 비즈니스 오브젝트에 요청하는 방법 만 알아야합니다. 더 중요한 것은 비즈니스 오브젝트에서 특정 일이 발생할 때 호출 될 규칙을 배치 할 수 있다는 것입니다. 따라서 프리젠 테이션 계층이 인벤토리 및 주문에 대한 주문을 데이터베이스에 직접 변경하는 대신, 비즈니스 오브젝트는 변경을 수행하는 방법을 알고 있고 프리젠 테이션 계층에서 판매가 발생하면 수정할 테이블을 알고 있습니다.

이렇게하면 정보 표시를 웹 사이트의 기본 로직과 지속성에서 분리 할 수 ​​있습니다. 참여하는 것은 좋은 계획입니다. 특히 웹 사이트가 어떤 시점에서 무엇을 할 것인지, 그리고 비즈니스 개체가 제공 할 인터페이스가 무엇인지 파악해야합니다. 그런 다음 이러한 요구 사항을 기반으로 비즈니스 개체를 구현합니다. 이러한 비즈니스 객체는 데이터베이스 구조 및 특정 비즈니스 로직에 대한 지식을 넣는 곳입니다 ("A가 발생하면 B와 C를 수행"등).

처음에는 많은 추가 작업처럼 보였으 나 실제로 가치가 있습니다.

관련 문제