데이터베이스 테이블을 객체로 사용 하시겠습니까?

Question

저는 구조적으로나 성능면에서 재구성하기 위해 기존 프로젝트를 시작했습니다. 나는 대개 프레임 워크로 EF를 사용하지만 Linq-to-SQL과 ADO에 익숙하다. 내가보고있는 바로는 웹 응용 프로그램이 실제 데이터베이스 테이블 &보기를 코드 내부의 객체로 사용한다는 것입니다. 예를 들어 테이블 'foo'를 사용하면 클래스를 사용하는 대신 객체로 사용할 수 있습니다. 트로프 데이터를 응용 프로그램 내부에 저장하고 마지막으로 DB/테이블에 삽입합니다. 나는 이것을 결코 보지 못했고 그것을 인식하지 못했기 때문에 이것이 "좋은"관행인가? 나는 마이크로 소프트가 그렇게 할 수있게 만들었다는 것을 의미한다. 그래서 "진정한"목적은 무엇인가, 장점/단점은 무엇인가?

답장 보내 주셔서 감사합니다. 친절한 답변

Answer 1

내 의견이 마음에 들었으므로 확장하겠습니다. 내가 테이블을 가지고 있다고 가정 해 보겠습니다.

Foo 
FooId int 
Desc varchar(32) 

Bar 
BarId int 
Desc varchar(32) 

이제 실제로 더 많은 것을 말하고 50 개의 테이블을 말하는 것처럼 보자. 나는 견과류 일 것이므로 손으로 모든 것을 만들고 싶지 않을 것입니다. ADO.NET을 사용하면 데이터 테이블을 만들고 잠재적으로 공예품을 손으로 만들 수 있습니다. 글쎄, Linq To SQL을 사용하면 대부분의 모델링을 처리하는 문서를 만들었지 만 데이터베이스가 거의 비슷한 정도로 제한되어있었습니다. 그러나 Entity Framework MS는 한 발 더 나아갔습니다. 이제 데이터베이스 계층, 중간 계층 및 개체 계층이 있습니다. '컨텍스트'가 원하는 것 이상으로 오브젝트를 조작하고 만들 수 있다고해도 과언이 아닙니다.

하지만 Entity Framework 6.1.3 모델을 만들고 내 데이터베이스를 선택하고 먼저 데이터베이스를 선택한다고 가정 해 봅시다.나는 객체를 추가 할 때 모델 표현을 얻습니다. 그리고 그것들은 나를위한 문맥 아래에 저장됩니다. EF에 관한 한 이러한 객체는 테이블입니다. 당신은 내가 방금 추가 한 새로운 푸 객체를 저장하고 나는 POCO 개체의 코드 생성을 할 필요가 없었어요

using(var context = new DBContext()) 
{ 
    var newFoo = new Foo { Id = 1, Desc = "A" }; 
    context.Foo.Add(newFood); 
    context.SaveChanges(); 
} 

그런 짓을. EF는 모델 개체를 선택하고 마우스 오른쪽 버튼을 클릭하고 '사용자 지정 도구 실행'을 선택하여 사용자 지정 도구를 실행할 때 저를 위해 저를했습니다. 본질적으로 이것은 POCO 및 설정을 생성하기 위해 데이터를 실행하는 것입니다. 또는 T4에 코드를 작성합니다. 설정을 변경하기 위해 T4를 업데이트 할 수 있지만 지나치게 미친 것은 권장하지 않습니다.

이미 내려가는 방법이 더 좋습니다. 새로운 방법으로 코드를 감싸고 저장소가 있습니다. 리포지토리의 이점은 EF 컨텍스트를 인라인으로 말하면 기술을 혼합하거나 필요에 따라 변경할 수 있다는 것입니다. 제가 말하고자하는 유일한 것은 여러분이 사용하는 객체를 EF 나 다른 기술이 생성하는 것으로 유지하는 것입니다. 아니면 자동 호출하는 속성을 가진 비즈니스 로직을 가지고있을 수도 있습니다. 물론 EF를 오염시키지 않고 Repo 패턴으로 사용할 수 있습니다. 리포지토리 패턴 IMHO는 CRUD 작업이 검색 기술과 호출 부분 사이에 있어야한다는 중재자 여야합니다.

Answer 2

나는 자바와 C#에서 객체로 사용되는 리포지토리를 보아왔다. 나는 이것이 당신이 여기서 말하는 것에 대한 것입니다. 그렇다면 상당한 상충 관계가 있습니다. 모트 툴과 마찬가지로 사용법보다 사용 방법이 더 중요하므로 담요 사용 규칙을 사용하면 트레이드 오프를 이해하는 것이 더 중요합니다.

일반적으로 리포지토리에는 데이터 저장 및 가져 오기를 담당하는 개체가 있습니다. 이는 데이터베이스 테이블과 같이 작동 할 수 있지만 실제로 데이터베이스와 응용 프로그램 사이에있는 추상화입니다. 이것으로 당신은 물체를 유지하고 그것으로부터 당신은 물체를 요구합니다. 저장소는 객체의 내부에 대한 지식이 없으며 객체를 저장하거나 가져 오는 방법 만 알고 있습니다. 예를 들어 Spring의 일반적인 패턴입니다.

리포지토리는 데이터 액세스 개체와 매우 유사합니다 (실제로 일부 사람들은 동일한 것으로 주장하고 다른 사람들은 그렇지 않다고 주장합니다).

이점은 당신이이 추상화를 가지고 있기 때문에 나중에 오브젝트를 다른 곳에 저장하고 싶다면 (예를 들어 Kafka에 쓰고 나중에 데이터베이스에 쓰고 싶을 때) 이것을 할 수있는 저장소가 있어야합니다 . 따라서 저장소는 데이터를 얻거나 지속시키는 방법을 알려줄 필요가 없습니다. 그렇게하기로 결정한 API 만 구현하면됩니다.

여기서 가장 큰 이점은 비즈니스 로직을 지속성 로직과 분리한다는 것입니다. 즉, 비즈니스 로직을 지속성 로직에서 분리한다는 것입니다. 단점은 이것들은 여전히 ​​단단히 결합되어 있기 때문에 추상화는 당신이 생각하는 것만 큼 당신을 사지는 않는다고 생각할 수도 있고 생각보다 복잡 할 수도 있습니다.

SQL Server의 테이블에 대해이 작업을 수행하는 코드 생성기가 있습니다. 그러나이를 수행하는 순간 코드 생성기의 API 결정에 어느 정도 동점이 맺어지기 때문에 처음에는 추상화의 목적을 부분적으로 무효화합니다.