메서드를 넣을 위치입니다. 저장소상의 서비스 계층 (BL)?

Question

나는 혼란 스럽다. 이전의 mvc 응용 프로그램에서 저장소 패턴 (일반이 아님)을 사용했으며 일부 비즈니스 로직을 여기에 포함 시켰습니다. 이 순간에 나는 BL에 포함되어야하는 서비스 계층 패턴을 읽었다. 하지만 이제는 더 명확하고 읽기 쉽고 효율적인 코드 대신 추상화와 추가 코드가 있는지 알 수 없습니다.

은 내가 하나 개의 필드의 상태를 변경하는 비즈니스 로직의 비트가이 코드에서이

public void ChangeActiveField(bool isActive, int id) 
{ 
    var objectToUpdate = _context.FirstOrDefault(x=>x.id==id); 
    objectToUpdate.IsActive - isActive; 
    _context.Entry(objectToUpdate).State = System.Data.Entity.EntityState.Modified; 
    _context.Save(); 
} 

같은 방법을 구현하려는 그 후 나는이 업데이트됩니다. 서비스 계층에서 만들어야하며 간단한 저장소 업데이트 방법을 사용해야합니다.

public class MyService 
{ 
    private readonly IMyRepository = _myRepo; 

    MyService(IMyRepository myRepo) //it's injectable 
    { 
    _myRepo = myRepo; 
    } 

    public void ChangeActiveField(bool isActive, int id) 
    { 
    var myObject = _myRepo.GetMyObject(id); 
    myObject.IsActive = isActive; 
    _myRepo.Update(myObject); 
    } 

} 

더 나은가? 더 나은 분리를합니까? 아니면 너무 정교하고 덮어 씁니까? 도움 주셔서 감사합니다. 감사합니다.

Answer 1

일반적으로 저장소는 에만 액세스 (액세스 컨텍스트, 트랜잭션, 연결 등) 논리를 캡슐화해야합니다. 일반적인 CRUD 저장소를 만들고 모든 비즈니스 엔티티에 다시 사용하는 것은 매우 일반적입니다. 모든 비즈니스 관련 논리는 비즈니스 계층 (서비스 계층)에 배치되어야합니다. 이 방법의 주요 장점은 다음과 같습니다

1. 테스트 용이성 - 당신이 가짜 저장소 (스텁)를 주입하여 콘크리트 저장소 구현에 의존하지 않고 비즈니스 로직을 테스트 할 수 있습니다.
2. 디커플링 - 비즈니스 계층도 UI도 특정 데이터베이스와 결합되지 않습니다. 내일 SQL 서버에서 Redis (NoSQL 데이터베이스)로 데이터베이스 마이그레이션을 결정하면 변경 사항은 리포지토리 계층에만 포함됩니다.
3. 유지 관리 성 - UI와 사용자 간의 상호 작용, 비즈니스 로직의 구현, 리포지토리 - DB와의 상호 작용 등 각 계층에 대한 관심이 명확하게 구분됩니다.

비즈니스 계층을 가지고있는 나의 경험으로는 (처음에는 아무리 간단하다해도 프로젝트와 함께 성장하는 경우가 많습니다.) 항상 좋은 아이디어입니다.

그런데 일부 개발자는 EF를 사용하는 경우 (예 : EF 데이터베이스 컨텍스트가 리포지토리 인 경우) 저장소를 불필요한 추상화 계층으로 간주합니다.

내가 배운 한 가지 중요한 사항은 프로젝트의 개발 단계가 아니라는 것입니다. 유지 관리 및 업그레이드이며 여기서는 비즈니스 계층에 큰 영향을 미칩니다.

면책 조항 :이 같은 작은 예제와 내 경험