나는 아직도 좋은 옛날 저장소를 기억합니다. 그러나 저장소는 시간이 지남에 따라 못 생겼습니다. 그런 다음 CQRS가 주류를 얻었습니다. 그들은 좋았고, 신선한 공기를 마셨다. 그러나 최근에 나는 컨트롤러의 Action 메소드 (특히 액션이 자체적으로 일종의 명령 / 쿼리 처리기 인 Web Api)에서 로직을 유지하지 않는 이유를 반복해서 묻고 있습니다.
이전에는 그에 대한 명확한 답을 얻었습니다. 모든 단일 한 싱글 톤과 전체적으로 추악한 ASP.NET 인프라로 Controller를 테스트하기가 어렵 기 때문에 테스트를 위해 수행합니다. 그러나 시간이 바뀌었고 현재 ASP.NET 인프라 클래스는 훨씬 더 단위 테스트에 익숙합니다 (특히 ASP.NET Core에서).
일반적인 WebApi 호출은 다음과 같습니다. 명령이 추가되고 이에 대한 SignalR 클라이언트에 알림이 표시됩니다.
public void AddClient(string clientName)
{
using (var dataContext = new DataContext())
{
var client = new Client() { Name = clientName };
dataContext.Clients.Add(client);
dataContext.SaveChanges();
GlobalHost.ConnectionManager.GetHubContext<ClientsHub>().ClientWasAdded(client);
}
}
쉽게 단위 테스트 / 모의 할 수 있습니다. 또한 OWIN 덕분에 로컬 WebApi 및 SignalR 서버를 설정하고 통합 테스트를 할 수 있습니다 (그리고 매우 빠릅니다).
최근에는 성가신 Commands / Queries 핸들러를 작성하려는 동기가 점점 줄어들었고 웹 API 작업에서 코드를 유지하는 경향이 있습니다. 논리가 반복되거나 실제로 복잡하고 분리하려는 경우에만 예외를 만듭니다. 그러나 내가 옳은 일을하고 있는지 확실하지 않습니다.
일반적인 최신 ASP.NET 응용 프로그램에서 논리를 관리하는 가장 합리적인 방법은 무엇입니까? 코드를 명령 및 쿼리 처리기로 옮기는 것이 합리적입니까? 더 나은 패턴이 있습니까?
최신 정보. DDD-lite 방식에 대한 이 기사 를 찾았습니다 . 따라서 코드의 복잡한 부분을 명령 / 쿼리 처리기로 옮기는 접근법을 CQRS-lite라고 할 수 있습니다.