PS: i don't want to over complicate the project by adding IRepositories interfaces which would probably allow me to keep EntityFramework and Domain separate.
its really a bad idea, once i had this opinion but honestly if you dont program to abstraction it will become a pain when the project becomes larger. (a real pain) IRepositories help you spread the job between different team members also. in addition to that you can write many helper extensions for Irepository to encapsulate Different Jobs for example
IReopisotry<File>.Upload()
you must be able to test each layer independently and tying them together will let you only do an integration tests with alot of bugs in lower layers :))
-------------------First, I think this question is really opinion based.
According to the Big Book the domain models must be separated from the data access. Your domain has nothing to with the manner of how storing the data. It can be a simple text file or a clustered mssql servers.
This choice must be decided based on the actual project. What is the size of the application?
The other huge question is: how many concurrent user use the db and how complex your business logic will be.
So if it's a complex project or presumably frequently modified or it has educational purposes then you should keep the domain and data access separated. And should define the repository interfaces in the domain model. Use some DI component (personally I like Ninject) and you should not reference the data access component in the services.
물론 몇 가지 moq 도구를 사용하여 레이어를 개별적으로 테스트하는 테스트 프로젝트도 만들어야합니다.
예, 이것은 잘못된 것입니다. 도메인 기반 설계를 따르는 경우 작업을 줄이기 위해 아키텍처를 손상해서는 안됩니다. 데이터 액세스와 도메인은 별도로 유지해야합니다. 장기적으로 더 많은 유연성을 허용하므로 Repository 패턴을 구현하는 것이 좋습니다.
-------------------물론 올바른 디자인이 무엇인지에 대한 정답
이 있습니다.하지만 EF가 데이터 레이어 추상화 라고 주장 합니다. 리포지토리를 사용하여 더 강력하고 유연한 것을 만들 수있는 방법은 없습니다.
코드 반복을 피하기 위해 일반적인 작업에 대한 확장 메서드 (IQueryable <> 용)를 쉽게 작성할 수 있습니다.
도메인 계층의 단위 테스트는 큰 DB를 일부 in-proc DB (SqlLite / Sql Server Compact)로 대체하여 쉽게 처리 할 수 있습니다.
nHibernate 및 EF와 같은 현재 ORM의 성숙도를 가진 IMHO는 DB 액세스와 같은 단순한 저장소를 구현하는 데 막대한 돈과 시간 낭비입니다.
더 자세한 답변이 포함 된 블로그 게시물http://ayende.com/blog/4784/architecting-in-the-pit-of-doom-the-evils-of-the-repository-abstraction-layer
출처
https://stackoverflow.com/questions/22089832