이 포스트를 만든 목적
- 이제 34항목을 끝내려고
이 포스트의 준비물
- gVim 7.2
- Microsoft Visual C# 2010 - 확실히 20% 부족하다.
참고 서적
- Effective C#
내용
무엇이 웹 API 라고 하는가?
웹 API 라고 하기 보다는, 네트워크 API 라고 하는게 더 좋다. 서버나 원격지에 요청하는 작업이나, 요청 작업의 결과를 받는 작업의 API를 뜻한다.
그런데 왜 크게 만들어야 하는가?
- 네트워크를 이용한 작업이기 때문에, 송/수신율이 로컬보다 느리기 때문이다.
- 네트워크 전송량이 많이 소모 되기 때문이다.
그럼, 어떻게 만들어야 하는가?
예를 들어, 팩스를 이용해서 다음과 같이 작업한다고 봐보자.
- 나 : 누구 견적서 좀 보내줘. 라고 종이에 적고 팩스로 전송
- 너 : 아이디가 어떻게 되는데?, 라고 종이에 적고 팩스로 전송
- 나 : asdf 라고 적고 팩스로 전송
- 너 : 언제적 견적서? 라고 적고 팩스로 전송
- 너 : 어제꺼 라고 적고 팩스로 전송
....
어떤가? 이 작업을 나 스스로 하면, 그냥 쭉쭉 할 수 있으나, 네트워크를 겪는 과정이라면, 정말 답답하다. 그러므로, 하나의 요청 작업을 더 이상 물어 볼 필요가 없도록, 한번에 보내고, 한번에 받는 형태로 만들어야 한다.
결론
- 한번에 처리 할 수 있는 과정을 네트워크 API 로 만드는게 좋다.
여담
- 한번의 send 보다 10,000번의 if 문이 더 빠르다.
- 그러고 보면, 이 항목은 네트워크 API 를 만드는 요령만 나와있다.
'책 정리 > Effective C#' 카테고리의 다른 글
item 39, 닷넷의 유효성 검증 기능을 사용하라. (0) | 2010.08.10 |
---|---|
item 38, 데이터 바인딩을 사용하라. (0) | 2010.08.04 |
item 37, 표준 환경설정 메커니즘을 이용하라 (0) | 2010.08.03 |
item 36, 닷넷 런타임의 진단기능을 활용하라 (0) | 2010.08.01 |
item 35, 이벤트 핸들러보다 override를 사용하는 편이 낫다. (0) | 2010.08.01 |
item 33, 타입의 가시성을 제한하라. (0) | 2010.08.01 |
item 32, 작고 응집도가 높은 어셈블리가 더 좋다. (0) | 2010.07.31 |
item 31, 작고 단순한 메서드가 더 좋다. (0) | 2010.07.25 |
item 30, CLS를 준수하는 어셈블리가 더 좋다. (0) | 2010.07.25 |
item 29. 기반 클래스의 변경이 영향을 줄 경우에만 new 한정자를 사용하라. (0) | 2010.07.22 |
최근댓글