3 가지 응용 프로그램이 있습니다. 각 부분은 내 솔루션의 다른 부분에서 종속성을가집니다. MVC 프로젝트 내에 IDependencyResolver을 구현했습니다. 이는 레이어 분리의 아키텍처 규칙을 위반하기 때문에 잘못된 방법입니다. 내 MVC 프로젝트는 DAL 계층을 참조했습니다. 나쁜 코딩 방법입니다. 별도의 클래스 라이브러리 프로젝트를 만들 수 있다는 것을 알고 있습니다. 그것은 내 솔루션의 다른 프로젝트에 대한 참조를 갖습니다. 모든 종속성을 해결합니다. 나는 그것이 최선의 방법이 아니라고 들었다. 더 좋은 방법이 있습니다. 내 솔루션의 각 프로젝트는 종속성을 소유해야합니다. 나는 그것을 모두 모으는 법을 모릅니다. 그래서이 유용한 기사를 찾았습니다 : Dependency Injection Best Practices in an N-tier Modular Application하지만 너무 복잡하고 복잡해 보입니다. 다른 방법이 있습니까? 나는 비슷한 구조의 솔루션을 가지고있다. UserRepository은 요청 된 사용자를 반환합니다.N 계층 응용 프로그램에서 IDependencyResolver를 구현하는 방법은 무엇입니까?
public interface IUserRepository
{
IEnumerable<UserEntity> GetAll();
}
public class UserRepository : IUserRepository
{
public IEnumerable<UserEntity> GetAll()
{
// some code
}
}
UserService은 몇 가지 서로 다른 종속성을 가질 수 있습니다.
public interface IUserService
{
IEnumerable<UserModel> GetAll();
}
public class UserService : IUserService
{
private readonly IUserRepository userRepository;
private readonly ISecondRepository secondRepository;
private readonly IThirdRepository thirdRepository;
public UserService(IUserRepository userRepository, ISecondRepository secondRepository, IThirdRepository thirdRepository)
{
this.userRepository = userRepository;
this.secondRepository = secondRepository;
this.thirdRepository = thirdRepository;
}
public IEnumerable<UserModel> GetAll()
{
// some code
}
}
마지막으로 UserController 생성자에는 많은 서로 다른 종속성이있을 수 있습니다.
제 질문은 아키텍처 규칙을 위반하지 않도록 이러한 종속성을 해결할 수있는 권리와 가장 간단한 방법은 무엇입니까? 당신은 당신이 종속성을 구성하는 추가 레이어를 만들 수 있습니다 말했듯이
런타임의 레이어 분리 규칙을 생각해보십시오. 응용 프로그램이 종속성 해석자에 의해 부트 스트랩 될 때 해석기를 올바르게 매핑 한 경우이 규칙을 따릅니다. 이 답변을보십시오 http://stackoverflow.com/questions/40401900/bootstrapping-unity-composition-root-location/40403875#40403875 –
가능한 중복 [IOC/DI - 왜 모든 레이어/어셈블리를 참조해야합니까? 엔트리 응용 프로그램에서?] (http://stackoverflow.com/questions/9501604/ioc-di-why-do-i-have-to-reference-all-layers-assemblies-in-entry-application) – NightOwl888