리포지토리 패턴 대 DAL

리포지토리 패턴 대 DAL

---

그들은 같은 것입니까? Rob Connery의 Storefront 튜토리얼 시청을 마쳤으며 유사한 기술인 것 같습니다. 즉, DAL 개체를 구현할 때 GetStuff, Add / Delete 등 메서드가 있고 나중에 db를 전환 할 수 있도록 항상 인터페이스를 먼저 작성합니다.

내가 헷갈 리나요?

---

당신은 확실히 일을 혼동하는 사람이 아닙니다. :-)

나는 질문에 대한 답은 당신이 얼마나 순수 주의자가되고 싶은지에 달려 있다고 생각합니다.

엄격한 DDD 관점을 원한다면 한 길을 내려갈 것입니다. 리포지토리를 서비스와 데이터베이스를 분리하는 계층의 인터페이스를 표준화하는 데 도움이 된 패턴으로 보면 다른 작업을 중단하게됩니다.

제 관점에서 저장소는 데이터에 대한 액세스의 명확하게 지정된 계층 일뿐입니다. 즉, 데이터 액세스 계층을 구현하는 표준화 된 방법입니다. 저장소 구현에 따라 약간의 차이가 있지만 개념은 동일합니다.

어떤 사람들은 저장소에 더 많은 DDD 제약을 두는 반면 다른 사람들은 데이터베이스와 서비스 계층 사이의 편리한 중재자로서 저장소를 사용할 것입니다. DAL과 같은 리포지토리는 데이터 액세스 세부 사항에서 서비스 계층을 분리합니다.

그것들을 다르게 만드는 것으로 보이는 구현 문제 중 하나는 저장소가 종종 사양을 취하는 메소드로 생성된다는 것입니다. 저장소는 해당 사양을 충족하는 데이터를 반환합니다. 내가 본 대부분의 기존 DAL에는 메서드가 여러 매개 변수를 사용하는 더 큰 메서드 집합이 있습니다. 이것은 작은 차이처럼 들릴지 모르지만 Linq와 Expressions의 영역에 들어가면 큰 문제입니다. 기본 저장소 인터페이스는 다음과 같습니다.

public interface IRepository : IDisposable
{
    T[] GetAll<T>();
    T[] GetAll<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter);
    T GetSingle<T>(Expression<Func<T, bool>> filter, List<Expression<Func<T, object>>> subSelectors);
    void Delete<T>(T entity);
    void Add<T>(T entity);
    int SaveChanges();
    DbTransaction BeginTransaction();
}

DAL입니까, 리포지토리입니까? 이 경우에는 둘 다 추측합니다.

김

---

리포지토리는 다양한 방식으로 적용 할 수있는 패턴이지만 데이터 액세스 계층에는 매우 명확한 책임이 있습니다. DAL은 CRUD 작업을 수행하기 위해 데이터 저장소에 연결하는 방법을 알아야합니다.

리포지토리 는 DAL 이 될 수 있지만 DAL 앞에 배치되어 비즈니스 개체 계층과 데이터 계층 사이의 다리 역할을 할 수도 있습니다. 어떤 구현이 사용되는지는 프로젝트마다 다릅니다.

---

한 가지 큰 차이점은 DAO는 도메인의 모든 엔티티에 대한 지속성을 처리하는 일반적인 방법이라는 것입니다. 반면에 저장소는 집계 루트 만 처리합니다.

---

나는 비슷한 질문에 대한 답을 찾고 있었고 가장 높은 두 개의 답변에 동의합니다. 이것을 명확히하기 위해 Repository 패턴과 밀접한 관련이 있는 사양이 도메인 모델의 일급 구성원으로 구현되면

• 다른 매개 변수로 사양 정의를 재사용합니다 .
• 기존 사양 인스턴스의 매개 변수 조작 (예 : 전문화)
• 결합 하고
• 데이터베이스에 액세스하지 않고도 비즈니스 로직 을 수행 합니다.
• 물론 실제 리포지토리 구현과 관계없이 단위 테스트를 수행합니다.

난 지금까지와 상태에 있음을 갈 수 없는 한 "저장소"저장소 패턴이 사양 패턴과 함께 사용되는, 정말 아니에요하지만 DAL. 의사 코드의 인위적인 예 :

specification100 = new AccountHasMoreOrdersThan(100)
specification200 = new AccountHasMoreOrdersThan(200)

assert that specification200.isSpecialCaseOf(specification100)

specificationAge = new AccountIsOlderThan('2000-01-01')

combinedSpec = new CompositeSpecification(
    SpecificationOperator.And, specification200, specificationAge)

for each account in Repository<Account>.GetAllSatisfying(combinedSpec)
    assert that account.Created < '2000-01-01'
    assert that account.Orders.Count > 200

자세한 내용은 Fowler의 사양 에세이 를 참조하십시오 (위의 내용을 기반으로 한 것입니다).

DAL에는 다음과 같은 특수한 방법이 있습니다.

IoCManager.InstanceFor<IAccountDAO>()
    .GetAccountsWithAtLeastOrdersAndCreatedBefore(200, '2000-01-01')

You can see how this can quickly become cumbersome, especially since you have to define each of the DAL/DAO interfaces with this approach and implement the DAL query method.

In .NET, LINQ queries can be one way to implement specifications, but combining Specification (expressions) may not be as smooth as with a home-grown solution. Some ideas for that are described in this SO Question.

---

My personal opinion is that it is all about mapping, see: http://www.martinfowler.com/eaaCatalog/repository.html. So the output/input from the repository are domain objects, which on the DAL could be anything. For me that is an important addition/restriction, as you can add a repository implementation for a database/service/whatever with a different layout, and you have a clear place to concentrate on doing the mapping. If you were not to use that restriction and have the mapping elsewhere, then having different ways to represent data can impact the code in places it shouldn't be changing.

---

It's all about interpretation and context. They can be very similar or indeed very different, but as long as the solution does the job, what is in a name!

---

Advantage of using repository pattern is to mock your data access layer, so that you can test your business layer code without calling DAL code. There are other big advantages but this seems to be very vital to me.

---

From what I understand they can mean basically the same thing - but the naming varies based on context.

For example, you might have a Dal/Dao class that implements an IRepository interface.

Dal/Dao is a data layer term; the higher tiers of your application think in terms of Repositories.

---

So in most of the (simple) cases DAO is an implementation of Repository?

As far as I understand,it seems that DAO deals precisely with db access (CRUD - No selects though?!) while Repository allows you to abstract the whole data access,perhaps being a facade for multiple DAO (maybe different data sources).

Am I on the right path?

---

In the external world (i.e. client code) repository is same as DAL, except:

(1) it's insert/update/delete methods is restricted to have the data container object as the parameter.

(2) for read operation it may take simple specification like a DAL (for instance GetByPK) or advanced specification.

Internally it works with a Data Mapper Layer (for instance entity framework context etc) to perform the actual CRUD operation.

What Repository pattern doesn't mean:-

Also, I've seen people often get confused to have a separate Save method as the repository pattern sample implementation besides the Insert/Update/Delete methods which commits all the in-memory changes performed by insert/update/delete methods to database. We can have a Save method definitely in a repository, but that is not the responsibility of repository to isolate in-memory CUD (Create, Update, Delete) and persistence methods (that performs the actual write/change operation in database), but the responsibility of Unit Of Work pattern.

Hope this helps!

---

Repository is a pattern, this is a way to implement the things in standardized way to reuse the code as we can.

참고URL : https://stackoverflow.com/questions/291344/repository-pattern-vs-dal