서버에서 데이터가 넘어온다고 거장하자. 인터렉터에서 로직을 수행한 후, 프레젠터로 넘어가기 전에 데이터에 대한 오류처리를 하고, 데이터가 이상하다면 그에 맞는 행위를 프레젠터에 넘겨주면 된다. 그렇다면 이전 화면에서 데이터가 넘어올 경우를 가정한다면, 이 또한 비슷하게 수행할 수 있다. 인터렉터에서 데이터를 받은 후, 데이터가 이상하다면 바로 프레젠터로 이전 화면으로 돌아가라고 알려줄 수 있거나 혹은 오류 화면을 프레젠트할 수 있다.
인터렉터에서는 여러 비즈니스 로직들을 수행한다. 서버에서 데이터를 받아오거나, Cache된 데이터가 있는지 확인하거나, 이전 화면에서 데이터를 넘겨받으면 데이터를 프레젠터로 넘겨준다. 이와 같은 작업은 VC에서 몰라도된다. 즉, VC는 자신이 호출한 함수가 서버에서 의해서 혹은 코어데이터에서 등, 어떤 로직에 의해서 데이터를 받는지는 알 필요가 없다.
따라서 해당 이슈에서 말한대로 BusinessLogic 프로토콜에는 fetch로 메소드 이름을 짓는다. 만일, 데이터를 받아오는 작업이 아니라면 request라고 이름을 짓는다.
HoJongE
commented
2 years ago
생각
개발도중에 생긴 의문점들에 대해 작성을 해두려고 한다.
뷰에 뿌려지는 데이터들의 오류처리는 어디에서 해야할까? (0722)
서버에서 데이터가 넘어온다고 거장하자. 인터렉터에서 로직을 수행한 후, 프레젠터로 넘어가기 전에 데이터에 대한 오류처리를 하고, 데이터가 이상하다면 그에 맞는 행위를 프레젠터에 넘겨주면 된다. 그렇다면 이전 화면에서 데이터가 넘어올 경우를 가정한다면, 이 또한 비슷하게 수행할 수 있다. 인터렉터에서 데이터를 받은 후, 데이터가 이상하다면 바로 프레젠터로 이전 화면으로 돌아가라고 알려줄 수 있거나 혹은 오류 화면을 프레젠트할 수 있다.
BusinessLogic에 들어가는 메소드의 네이밍 (0720)
인터렉터에서는 여러 비즈니스 로직들을 수행한다. 서버에서 데이터를 받아오거나, Cache된 데이터가 있는지 확인하거나, 이전 화면에서 데이터를 넘겨받으면 데이터를 프레젠터로 넘겨준다. 이와 같은 작업은 VC에서 몰라도된다. 즉, VC는 자신이 호출한 함수가 서버에서 의해서 혹은 코어데이터에서 등, 어떤 로직에 의해서 데이터를 받는지는 알 필요가 없다. 따라서 해당 이슈에서 말한대로 BusinessLogic 프로토콜에는 fetch로 메소드 이름을 짓는다. 만일, 데이터를 받아오는 작업이 아니라면 request라고 이름을 짓는다.