정규화 테이블 (ACID)

Question

두 부분 질문 :

번호 1 : 다른 객체를 참조하는 객체 모델을 만드는 가장 좋은 방법은 무엇입니까 때 속성/속성의 일부 참조 된 객체의 이름이 항상 필요한 것은 아닙니다. PERSON 위의 예에서 사업

Person 
+ PersonID 
+ Name 
+ Age 
+ Sex 
+ Skill 
+ Business * 

Business 
+ BusinessID 
+ Name 
+ Address 
+ CorporateVision (this is large) 

: PERSON 현재의 고용주로 사업에 대한 참조가 두 객체가있는 경우

은 상상 해보세요.

데이터베이스에는 각 개체에 대해 두 개의 테이블이 있습니다. 코드에서 MVC 아키텍처 패턴을 사용하는 동안 각 객체에 대해 두 개의 클래스가 있습니다. 코드에서 PERSON 목적은 BUSINESS 객체에 대한 참조를 보유 부재 변수를 가질 것이지만,>PERSON - 데이터베이스는 BUSINESS간에 외래 키 관계를 가질 것이다.

이제 내가 및 신체의 컬렉션 열거하고 특정 회사에 근무하는 사람들의 총 수를 찾아하고 싶은 말은하자 (사업. 이름 기준).

MVC를 사용하지 않고 데이터베이스를 쿼리하고 카운트하는 함수를 만들 수 있습니다. 간단하고 효율적입니다.

는 MVC와 함께, 나는 회전에서, 하나는 이미 그것을 수행하지 않은 경우 ... BusinessFactory이 컬렉션을 확인할 것입니다 (참조에 대한 사업 객체를 인스턴스화 모든 PERSON 개체를 인스턴스화 할 필요가 먼저). 또한 영업을 반드시 입력해야합니다. CorporateVision 모든 개체에 대한 데이터베이스입니다. 그리고 이러한 기업의 대부분이 미디어 마케팅 회사이기 때문에 기업 비전의 대부분은 대형 텍스트 얼룩입니다. 따라서 우리가 필요한 모든 것이 비즈니스의 이름 일 때 데이터베이스에서 CorporateVision을 읽는 것은 매우 불필요합니다.

I가 코드에서 PERSON 객체를 변경함으로써이 문제를 해결할 수 : 그래서 지금은 내 PERSON 개체를 만들 때

Person 
+ PersonID 
+ Name 
+ Age 
+ Sex 
+ Skill 
+ BusinessID 
+ BusinessName 

, 나는이 사업에 가입하고 캐시 할 이름. 이제 BusinessName을 빠르고 효율적으로 가져올 수 있습니다 ... 그리고 여전히 전체를 얻을 수 있습니다. 영업 ID에 대한 조회를 수행하여 필요에 따라 개체를 만듭니다. 하지만 모델을 비정규 화했습니다 ... 그리고 방금 새로운 문제와 새로운 질문을 도입했습니다.

2 번 MVC는 다중 사용자 데이터베이스와의 동시성을 어떻게 처리합니까?

내 클라이언트 응용 프로그램이 위에서 언급 한 특정 비즈니스에 적합한 모든 사람들을 찾는 열거 형을 사용하는 동안 다른 사용자가 BUSINESS 개체 중 두 개를 병합했다고 가정 해 보겠습니다.

이제 모든 BusinessName 캐싱이 부실하므로 내 메모리 수집이 잘못되었습니다. 내가 방금 떠났 더라도 마찬가지 일 수있다. PERSON. 비즈니스으로 비즈니스 개체 참조 : 비즈니스 개체는 오래 될 것입니다.

요약 : : MVC를 사용하면 데이터 검색 효율이 떨어지고 응용 프로그램의 ACID가 손실 될 수도 있습니다. 아니면 MVC를 잘못 사용하고 있습니까?

Answer 1

UI와 데이터 액세스를 혼합하는 것처럼 보이지만 다른 것들과의 의존성을 최소화해야합니다. MVC는 실제로 애플리케이션이 사용자와 상호 작용하는 방식을 설명하는 매우 폭 넓은 패턴입니다. 두 가지 질문은 모두 데이터 액세스와 관련이 있습니다.

1) MVC는 UI를 구성하는 방법입니다. 따라서 모델은 사용자가 상호 작용하게하려는 정보입니다. 여기서는 비즈니스 객체가 우선 순위가 아니라는 점에 유의하십시오. 사용시 Business의 여러 속성과 함께 Person 클래스가로드되는 경우 두 번째 Person rendition이이 경우에 대한 완벽한 모델입니다. 각 유스 케이스마다 다른 모델이 필요하며 여러 시나리오에 대해 서로 다른 모델을 만들어야합니다.

숫자를 계산하는 함수를 호출하는 것이 더 쉽다고 생각하면 좋습니다. 여기서 비즈니스 객체에 구속되지는 않는다는 것을 기억하십시오. 더 'object' 중심의 접근 방식으로

우리는 일반적으로 두 가지 방법이 참조 문제를 해결 : 현대적인 O/RM에 대한 아웃 - 오브 - 박스 기능입니다 함께

• 첫 번째는, 지연로드입니다. 그래서 Person을로드하고 Person.Business에 대한 첫 번째 호출 후에 후자가 자동으로로드됩니다.
• 두 번째는 데이터 액세스 특성을 인식하고 사용하는 필드 만 있거나 클라이언트에서 비동기 방식으로 추가 데이터를 요청하는 특별한 종류의 UI를 만드는 것입니다.

2) 다시 말하지만 MVC는 동시성을 처리하지 않으므로 처리하지 않아야하며 걱정할 필요가 없습니다. 데이터 액세스 계층의 문제입니다. 또한 동시성을 다루는 방법에는 여러 가지가 있으며, 그 중 주요한 것은 낙관적이고 비관적 인 잠금입니다. (처음에는 서로 다른 사용자가 충돌하는 변경을 수행하고 충돌이 발생하면이를 해결하려고합니다. 두 번째 방법은 업데이트를 완전히 잠그면 충돌을 방지합니다. 다시, O/RM은 일반적으로이를 처리합니다. 또는 자신의 구현을 사용할 수 있지만 MVC 부분이 아니라 데이터 액세스 여야합니다.