오늘 면접 본 회사에서 본 기술 시험 복습입니다.
원래 이런 글 올리면 댓글도 없고 이 블로그에 좀 안 어울리기도 합니다만, 이 블로그를 IT관련으로 생각하시는 분도 있고하니(...) 복습의 차원에서 한번 올려봅니다. (이런 블로그가 아닌데...)
회사 이름은 안 쓸게요. 그쪽에서 검색해서 들어오기라도 하면 낭패니(응?)
====================================================================================================
자바의 장점
치기 귀찮으니 이미지 파일로 대체
AJAX의 장단점
Ajax의 장점
1. 페이지 이동 없이 고속으로 화면을 전환
2. 서버 처리를 기다리지 않고 비동기 요청이 가능
3. PHP 및 Perl등의 서버 측 처리를 각 PC에 분산 가능
4. 수신하는 데이터의 양을 줄일 수 있음
5. 실시간 인터렉티브 성능이 올라감
Ajax의 단점
1. 크로스 브라우저 처리의 노하우가 필요
브라우저에 구현된 JavaScript에 의존한다는 것은, 각 브라우저 간에 좀처럼 완전히 동일하게는 되어 있지 않은 구현을 보완하기 위한 ‘크로스 브라우저 처리’를 피하고 넘어갈 수 없다는 말이다. 다만 예전 브라우저가 대부분 도태된 현재는 ECMA나 W3C와 같은 표준에 준거한 브라우저가 많아서, ‘DHTML브라우저 전쟁’ 때 정도의 문제는 아니다.
2. Ajax를 쓸 수 없는 브라우저에 대한 대책도 필요
JavaScript와 XMLHttpRequest를 사용할 수 없는 브라우저에서 동작할 수 없으므로 거기에 대한 대책이 필요하다.
3. JavaScript부분은 오픈소스이기 때문에 차별화가 어려움
서버 측은 어찌되었건 클라이언트 측은 JavaScript이기 때문에, 확실히 오픈 소스이다. 이것은 큰 장점인 동시에 이 부분에서 차별화를 꾀하지 않으면, 힘든 경쟁에 동참해야 한다는 단점도 있다.
4. Http클라이언트의 기능이 한정되어 있음
IE에는 크로스 도메인 시큐리티(cross domain security)모델이 채용되어 있습니다. 이것은 IE가 동일한 웹사이트로부터의 데이터에 대해 여러 개의 창이 열려 맞물려 돌아가는 경우, 보안상의 배려로 클라이언트의 접근에 ‘도메인’을 사용하여 관리하는 것입니다. 요청의 대상 URL은 요청을 하는 페이지와 같은 도메인에 있지 않으면 안됩니다.
5. 보안에 대한 주의가 불가피
페이지 이동 없이 서버와 통신을 한다는 것은 동시에 눈에 보이지 않는 이면에서 동작함을 뜻하기도 하므로, 전보다 더욱 신중한 보안상의 주의가 요구된다. 예를 들어, 수신데이터가 악의의 외부 입력으로부터 소통이 될 가능성이 없나 등을 늘 경계하고 있을 필요가 있다.
6. 현재의 처리 상황에 대한 정보가 필요
페이지 이동 없이 처리가 진행된다는 것은 사용자가 현재의 처리 상태를 못보고 지나칠 가능성 있다. 예를 들어 “ 수신이 끝나있는데, 아직도 처리가 안 끝나 있다고 생각이 들어 몇 번이고 클릭을 눌러버리는” 상황을 피하기 위해서도, “now loading”같은 표시를 응답 수신 시에 프로그레시브 바(progressive bar)등으로 나타내주는 것이 친절할 것이다. 또한, 주소란의 URL에 ‘#’으로 시작하는 해쉬를 추가로 적어 넣어, 명시적으로 페이지를 전환하는 방법도 있다.
7. 요청을 남발하면 역으로 서버 부하가 늘 수 있음
Ajax 장점의 대부분은 서버 측의 일을 줄이고 오늘날 성능이 좋은 무수한 클라이언트 pc에 작업을 나눠준다는, 서버 부하의 감소에 있다. 하지만 그 의도와는 반대로 요청이 너무 빈번하게 일어나서 서버 및 회선 부하를 늘려 버리는 일도 있을 수 있다. 경쾌한 동작을 실현하기 위해서 데이터 전송 량 요청회수, 서버부하 등에 대해서 종합적인 판단과 튜닝이 필요하다.
AJAX가 뭐냐하면 이 블로그에 댓글을 달때 페이지가 바뀌지 않고 바로 댓글이 달리죠? 그게 AJAX를 이용한 겁니다. 페이지 전환없이 웹 페이지를 변경시키는 기술이죠.
Struts의 특징
Struts 프레임워크의 특징은 Model 2를 기준으로(물론 사용하기에 따라 Model 1으로도사용가능합니다) 만들어져 있다. 수많은 라이브러리 class들이 기본적으로 내장 되어있고, controller에 해당하는 파일이 xml 로 되어 있어서 context 가 추가되더라도 xml 파일만 추가해주면 바로 연결 해서 사용할 수 있다
• ActionServlet : 어떤 Action(비지니스 로직을 호출하는 역할을 하는 자바 클래스)를 사용할지 여부 등 스트럿츠 전반에 대한 설정을 저장하고 있는 struts-config.xml 파일을 읽어 저장하는 Servlet 클래스이다.
• RequestProcessor : 사용자의 요청을 받으면, struts-config.xml 설정에 따라 실제로 호출할 Action을 선택하고, request와 response 서블릿 객체를 이용해서 미리 선행작업을 하는 역할을 한다.
Action을 선택하는 방법은 바로 요청 URL에 있다.
예를 들어 사용자가 http://localhost:8080/login.do를 호출 했다면 “/login.do”를 인지하고 strutsconfig.xml에서 “/login”이라는 이름(“.do” 제외)으로 지정된 행동 지침관련 설정(<action>)을 찾아서 그에 따라 비지니스 로직을 실행시킨다.
• ActionForm : 사용자가 GET 혹은 POST 방식으로 넘긴 파라미터들을 저장하고 분석하여 알맞은 값이 들어왔는지 여부 등을 판단(유효성 검사)하는 Java Bean 이다. ActionForm은 있어도 되고 없어도 되며 ActionForm에서 각 파라미터가 유효성 검사를 통과하지 않으면 Action을 호출하지 않는다.
• Action : 비지니스 로직을 호출하는 부분이다. 실질적으로 자바 웹 서블릿과 같은 역할을 한다. 비지니스 로직은 Action에서 직접 수행하지 말고 따로 Model 전용 클래스로 만들어서 파라미터들을 넘겨 호출만 하는 형태로 작성한다.
JDBC
JDBC는 데이터베이스를 다루기 위한 자바 API(Application Programming Interface)이다
자바를 기반으로 하는 프로그램을 작성할 때 프로그래머에게 데이터베이스를 쉽게 다룰수 있게 합니다.
JDBC를 통해서 어떠한 DBMS일지라도 질의문을 던져서 데이터를 가져올 수 있습니다.
JDBC는 JDBC 인터페이스와 JDBC 드라이버로 구성
JDBC 인터페이스 : 데이터베이스와 연동되는 프로그램을 작성할 수 있게 하는 도구라 할 수 있습니다.
JDBC 드라이버 : JDBC 인터페이스를 구현하여 실제로 DBMS를 작동 시켜서 질의를 던지고 결과를 받습니다.
Oracle JOIN 예제
select e.employee_id, d.department_id from employees e
join departments d on (e.employee_id = d.department_id)
이건 아는 거였는데 착각해서 살짝 실수했네요. 젠장.
====================================================================================================
긴장해서 실수도 좀 한거 같은데 결과는 모르겠습니다. 진인사대천명이라고 기다려보는 수 밖에...
