Tag Archives: Framework

스파크 – 새로운 자바 웹 프레임워크

http://sparkjava.com/

스프링의 어노테이션 범벅 구조에 좀 질려있는 상황에서

간단히 메서드 체인 형태로 구성할 수 있는 프레임워크가 나와서 조금 반갑다.

그레일즈와 비슷한 구조?

다른건 제대로 써본게 없어서 정확히 비교를 못 하겠다.

아직은 초기라서 많은 기능지원이 없을 것 같다. 직접구현해도 나쁠것은 없지만….

회사일을 하다보면 그게 쉽지 않으니

추가적인 것은 나중에 확인.

2014 Web UI(JS,CSS) 프레임워크Framework & 라이브러리Library

최근 트렌드로 제시되고 있는놈들하고 기존 사용되던놈들…
여기없거나 설명이 매우 적은것들은 아주최신이라 서비스로 쓰기 좀 안좋을정도거나
오래되서 사용하지않는것들일 가능성이 높음.

PrimeFaces
게시판이나 이런거 등등 다양한 UI제공
http://www.primefaces.org/

ICEFaces
PRIME이랑 비슷한것?
http://www.icesoft.org/java/projects/ICEfaces/overview.jsf

RichFaces
Prime이랑 비슷한것역시..
http://www.jboss.org/richfaces

jQuery thermeroller
아코디언모양 메뉴
http://jqueryui.com/themeroller/

960-Grid-System
twitter 직원이 만든듯 싶다. 포토샵이랑 fireworkd에 설치해서 쓰는 템플릿?
대강 이렇게 만들어놓은건 파이어웍스에서 CSS를 자동생성해주는 기능이 아닐까 하는 느낌
http://code.tutsplus.com/tutorials/which-css-grid-framework-should-you-use-for-web-design–net-25
http://960.gs/

AngularJS
구글에서 나온 JS프레임워크
http://angularjs.org/
지원사이트 : http://angular-ui.github.io/
모듈모음 : http://ngmodules.org/
예제 : https://github.com/angular/angular.js/wiki/JsFiddle-Examples
Bootstrap연동 : http://angular-ui.github.io/
Tstacular JS 테스팅프레임웍 : http://testacular.github.io/
AngularJS 팁 : http://deansofer.com/posts/view/14/AngularJs-Tips-and-Tricks-UPDATED
한국유저그룹 : http://angularjs.co.kr/
페이스북그룹 : https://www.facebook.com/login.php?next=https%3A%2F%2Fwww.facebook.com%2Fgroups%2FKorea.AngularJS.User.Group%2F

Backbone.js
https://github.com/jeromegn/Backbone.localStorage
언더스코어 : http://underscorejs.org/
튜토리얼 : http://backbonetutorials.com/
관계형모델 : http://backbonerelational.org/
페이징 : https://github.com/backbone-paginator/backbone-pageable
폼생성 : https://github.com/powmedia/backbone-forms
Mustache템플릿엔진 : http://mustache.github.io/
Bootstrap연동GRID : http://direct-fuel-injection.github.io/bbGrid/
Backbone.js기반 프로젝트 시드 : https://github.com/backbone-boilerplate/backbone-boilerplate
Backbone.js기반 MVC프레임웍 : http://chaplinjs.org/

Prototype

jQuery
다른것들 쓰는데 jQuery만 빼놓을수 없어서…
UI : https://jqueryui.com/
kendoui라던가 뭐 이래저래 jquery기반으로 만들어진 유료라이브러리도 꽤 된다. 역사도 오래되서 버그도 많이없고… 또 익숙하고. SI에 특히 유용.(유지보수관점)

Bootstrap
요즘 거의 대세인 웹디자인 템플릿
http://getbootstrap.com/
템플릿 : https://wrapbootstrap.com/
예제제작도구 : http://bootsnipp.com/
한글사이트 : http://webdesigncss3.com/bootstrap/
적용사례 : http://builtwithbootstrap.com/
테마 : https://wrapbootstrap.com/
테마 : http://www.templatemonster.com/properties/features/bootstrap-templates/
테마 : http://themeforest.net/search?term=bootstrap
테마제작도구 : http://stylebootstrap.info/

blueprint
CSS프레임워크
http://blueprintcss.org/

Foundation
http://foundation.zurb.com

Skeleton
http://getskeleton.com

HTML KickStart
http://99lime.com

HTML5 BoilerPlate
http://html5boilerplate.com

Initializr
http://www.initializr.com

GLYPHICONS
아이콘 사이트.유료무료
http://glyphicons.com/
http://glyphicons.getbootstrap.com/

NextWebFramework 1 : 무거운 프레임워크와 복잡한 테스트

요즘 웹 프로젝트는 사양이 상당히 좋은 컴퓨터로도 가동시키는데 30초? 조금 안좋은 컴퓨터로 하면 1~2분 무거운 프로젝트라면 5분까지 걸리기도 한다.

어마어마하다.

화면하나 고치고 테스트를 해보려면 5분을 기다려야 할 수도 있다. 동적으로 로딩이 되지만… 무거운 프로젝트라면 이조차도 버겁다. 로딩하다가 Pergem어쩌고 하면서 멈춰버린다. 그러면 재시작을 해줘야하니까….

그래서 사용하는게 Unit 테스트…. 그런데 View는 어쩔건가

별수없이 서버를 올려야된다.

아니면 가벼운구조로 새 프로젝트를 생성하고서 테스트를 하거나…  뭐 어쨌든 저쨌든 귀찮은 과정을 거쳐야만 한다.

자바는 너무 과도하게 무거워졌다. 루비도 몇번 돌려보긴 했는데 역시 마찬가지다. 서버 올리는데는 조금 시간이 걸린다. html테스트하는것처럼 바로바로 로딩이 되질 않는다.

이건 확실히 문제가 있다.

 

이 부분을 개선하기 위해서 필요한 것은 역시 모듈화.

그렇다면 어떤 구조로 나눌것인가가 문제가 된다.

 

1. SSO 를 중심으로 각 기능별로 웹사이트를 나눠버린다.

2. View / Controller / Service / Model / DB 의 방향으로 각 모듈별로 나눈다.

1번은 흔히 사용되는 방식으로 프로젝트의 크기를 적절히 분할한다면 효과적인 방법일 수 있다.

그런데 개인적으로 2번의 방법을 시도해보고싶었다. 이유는 간단하다. 2번이 더 간단하고 더 가볍고 효율적이다. 다만… 적절한 아키텍처가 제시되지 않고 있다. (찾아봤는데 없어서 없다고 단정지었다)

 

2번의 방법을 View-Engine-Model 구조로 정의한다.

VEM(가칭)

각 업무담당자별로 모듈을 나눌 수 있다는게 장점이다. 협업을 줄여서 각 모듈간의 충돌을 최소화한다.

설계단계는 별로바뀌는게 없을 것 같다. 기획이 나오고 개발자와 회의를 거쳐 구현이 가능한지를 결정한 다음 스토리보드를 뽑아낸다. 도메인모델과 디비도 이 단계에서 어느정도 설계가 될거고.

이 모델의 강점은 여기있다. 뷰단계에서 데이터가 들어있는 것처럼 화면을 동적으로 보여줄 수 있다는 점.

입력할 데이터를 미리 정의된 프로토콜형태로 text로 저장시켜놓은 후 화면단코드(자바스크립트,css등)을 수정하면서 바로바로 확인하며 코딩이 가능하다.

//데이터 파일
user.json
[{
  name:"kim",
  occupation:"baek",
  address:"korea"},
{
  name:"park",
  occupation:"soo",
  address:"seoul"}
]

//자바스크립트 코드
//var user = {
//  name:"kim",
//  occupation:"baek",
//  address:"korea"
//}
var user = getData("user.json")[0];

<input name="name" type="text" value="{{user.name}}"/>
<input name="occupation" type="text" value="{{user.occupation}}"/>
<input name="address" type="text" value="{{user.korea}}"/>

대략이런식으로 매핑이 되게 할 수 있다.

현재 나와있는 jquery , angular 등의 JS라이브러리로 구현이 가능할것으로 보인다. 이 부분은 조금 더 검토필요…. 화면단은 좀 덜해봐서

어쨌든 데이터를 기다리지 않고 화면단의 변경이 가능하다는 점이 가장 큰 장점이다. 일반 SI회사에서 가장 요구사항 변경이 잦고 고객사에서 귀찮게 하는 부분이 이 화면단인데 이 부분에 대해 초기대응이 가능하고 변경이 적어진다는 것이 장점이다.

보안이슈가 있는 경우에는 view쪽에서 사용자 인증 필터를 깔아야되는 경우도 있을 수 있다.(있을수도 있다가 아니라 대부분 경우-필요없는데서도- 이런 요청을 하지 않을까 싶다. 인증시스템은 기존에 만들던대로 만들면된다.)

 

View – Engine간의 연결

Ajax와 RPC.

언어에 따라 달라지겠지만 표준은 ajax와 rpc가 될 것이다. 화면과 로컬서버간에 ajax로 통신을 하고 ajax로 데이터를 가져오는 것은 cross domain제약이 있기 때문에 rpc를 이용해 통신을 하도록 한다. 쓰리프트의 경우 js도 지원을 하기 때문에 더 편리?하게 사용이 가능할지도 모르겠따. 생각해보니 쓰리프트 js거치는게 이것과 비슷하게 생성이 됏떤것같다.

앞의 화면코드에서 User배열을 json형태로 받았는데 이 부분은 다음과 같은 파라미터를 전송해서 호출한다.

묶음배송기능. ajax호출시 여러개의 데이터를 한꺼번에 호출하는 경우가 많은데 이 경우 RPC에 부하가 크기 때문에 묶음배송기능이 필요하다. 그래서 파라미터는 배열로 전송한다.

request : [{메서드명, 데이터(테이블 or 도메인)명}, {} …]

response : {{rpc상태메세지}, {data}, {data}}

response Set 첫번째 데이터는 상태메세지다. Set이지만 텍스트형태니까 앞쪽에 포함시키면 앞쪽이 된다.

각 domain이 가공되는 형태는 pre/post handler resolver 등을 붙여서 후처리 가공할 수 있도록 지원한다.

화면단에 보일 데이터의 형태인 도메인과 디비에 저장될 테이블은 같은 형태가 아닐 수 있다. 화면단에서는 완성된 vo를 호출하기 때문에 뷰에서 필요로 하는 데이터를 쿼리만 입력하면 완성된 데이터로 출력을 해 준다. 이 부분에 대해서는 api를 만들면서 만들어본적이 있으니 간단할듯 싶다.

 

Model : Engine부분과 굳이 분리할 필요는 없다. 합쳐지는게 더 효율적이지 않을까

ORM을 사용할 경우 Engine에 상당부분 포함될 수 있다.
ActiveRecord 생각하다보니 Rails구조가 떠올랐는데….
이 구조가 왠지 레일즈와 닮은것같다.

ORM을 써도 그냥 쿼리를 넣을 경우에는 그냥 쿼리로 뽑아볼수도 있어야한다.

 

이걸 분리시키면 너무 복잡하니 그냥 View-Engine Structure로 하는게 나을것같다.

구체적인 아키텍처는 다음번에 이어서.