운명처럼 다시 만난 Tmax와 그리고 Tmax를 다닐 때보다 더 제품 공부를 해야하는 상황이 왔다
현재 이직한 회사에서 티맥스 관련 제품을 많이 사용하기 때문 그래서 우리의 개발툴인 (조만간 바뀐다고는 하지만) ProFrame에 대해서 공부를 하고 실제 코드를 볼 것이다!
ProFrame
TmaxSoft에서 개발한 ProFrame은 주로 금융, 공공기관에서 고성능 트랜잭션을 위해 사용 되는 것으로 통합 애플리케이션 프레임워크라고 생각하면 됨
특이하게도 모듈화된 구조로 구성되어 있음
DBIO, FileIO, EMB, Service, UI, Mapper 등등 나눠진 구조를 통해 높은 재사용성과 유지보수성을 확보함
-> 개발자는 순수 업무 로직만 구현하더라도 비즈니스 목적에 맞는 애플리케이션을 구축할 수 있음
ProFrame은 EMB (Enterprise Module Bus, 코딩없이 디자인만으로 프로그래밍이 가능한 모듈기반의 개발환경) 아키텍쳐 기반
아래 사진이 프로프레임의 예시인데 업무 단위별로 모듈이 분리되어 마치 flowChart같음
프로프레임은 단순 로컬 IDE처럼 보이지만 클라이언트 PC외에도 서버, DB서버가 구성되어야 해서 세팅이 조금 빡셈
하지만 위에 말한대로 다른 것들을 신경쓰지 않고 순수 업무 로직만 개발하면 됨
ProFrame의 전체 구성 구조
┌────────────────────┐
│ UI 모듈 │ ← 화면(XML 등) 정의 및 사용자 요청
└────────▲───────────┘
│
▼
┌────────────────────┐
│ Service 모듈 │ ← 비즈니스 로직 처리 (main 역할)
└────────▲───────────┘
│
▼
┌────────────────────┐
│ Mapper 모듈 │ ← 화면 ↔ 로직 ↔ DB 간 데이터 매핑
└────────▲───────────┘
│
┌───────┼────────┬────────┐
▼ ▼ ▼ ▼
DBIO FileIO EMB 기타 모듈
(DB 입출력) (파일 IO) (외부 연동 등)
Service 모듈
- Mapper를 통해 DBIO, FIleIO, EMB 호출
DBIO
- DB의 CRUD연산을 담당함
- SQL문이 하드코딩 되지 않고 .sql, .dbio파일로 모듈화
Mapper
- 입출력 파라미터 중계자 (데이터 매핑을 처리하는 모듈)
화면 입력값 <-> 비지니스 로직 <-> DBIO간 데이터 매핑 담당
FileIO 모듈
- 파일 입출력 처리 담당
- CSV, TXT등 외부 파일을 읽거나 쓰거나
EMB
- 타 시스템과의 연동처리 (API, 메세지, MQ)
다른 서버와 SOAP, MQ, TCP/IP로 통신
ex) 대외기간 (신용평가사, 보험사) 연동
UI 모듈
- 화면 정의 (XML기반) + 입력 폼
서버에서 전송한 데이터를 XML 혹은 HTML로 출력
실제 흐름 예시
-
사용자가 화면(UI)에서 사원번호 101 입력 후 조회 버튼 클릭
-
Service 모듈이 호출됨 → Mapper가 EMP_ID = 101로 매핑
-
Mapper가 EMP001.dbio 내 EMP_SELECT SQL 실행
-
결과값을 Mapper가 받아서 UI용 구조로 매핑
-
화면에 출력됨
ProFrame + Oracle 연동 흐름
ProFrame 프레임워크와 각 모듈 (Service, Mapper, DBIO) 등이 오라클 DB와 상호작용하며 데이터를 어떻게 주고 받는지 설명해본다면 아래와 같음
.ec -> Service 모듈
.pc -> DBIO 모듈
(.pc -> .c 로 프리컴파일 하려면... proc 소스.pc 그럼 소스.c 파일이 생기고요.... 그걸 gcc나 cc로 컴파일 하심 됨)
[UI 화면]
↓ 사용자의 입력
[Service 모듈 (.ec)]
↓ 비즈니스 로직 실행
[Mapper]
↓
[DBIO 모듈 (.pc)]
↓ SQL 실행
[Oracle DB]
↓ 결과 반환
[DBIO → Mapper → Service]
↓
[UI 화면에 결과 전송]시각화 예시
1. [화면] : emp_id = '101'
2. [Service] : 입력값 수신, call_mapper()
3. [Mapper] : emp_id → :EMP_ID 매핑
4. [DBIO] : SELECT ... WHERE emp_id = :EMP_ID
5. [OracleDB] : 결과 반환
6. [Mapper] : 결과 → 출력 필드로 매핑
7. [Service] : UI XML로 포장
8. [화면] : 결과 표시
구조
📦 io_dbio_***.jar
┣ nics.***.le**.dbio ← DAO/Repository (JDBC 또는 MyBatis)
┣ nics.***.le**.io ← Input/Output 모델 클래스
┣ nics.***.le**.lg***.ec ← Service 클래스 (비즈니스 로직)이 jar파일은 DBIO + IO + EC (비지니스로직)으로 모듈 단위 컴포넌트를 묶은 공통 Jar임
- iodbio**.jar : 모듈들의 집합을 묶은 JAR패키지로 재사용 목적
-- .dbio : DB접근을 담당 (DAO)
-- *.io : I/O객체 (request/response 모델)
-- .ec : 비지니스 로직 (서비스 계층) => 단 우리는 Java이지만 ec인 이유는 관습처럼 유지하기 때문
세부 전체 구조
우리 프로젝트의 경우 각 직군에 따라 볼 수 있는 메뉴가 다름
그래서
-
각 직군 별로 가장 큰 모듈이 존재하고
-
거기에서 각 페이지 (페이지 넘버링) 에 따른 jar파일이 존재함
-
그 jar파일 안에 세부 코드가 존재 -> dbio, io, shft, service 등등등
📦 MSA (직군 이름)
┣ 📂 PFM_MODULES ← ProFrame Studio의 전체 모듈 뷰
┃ ┣ 📂 PFM_DBIO ← DBIO 모듈 전용 보기
┃ ┣ 📂 PFM_STR ← Struct VO
┃ ┣ 📂 PFM_MSG ← 시스템 메시지 관리
┃ ┣ 📂 PFM_MAP ← Mapper 설정 보기
┃
┣ 📦 넘버링된 화면들
┃ ┣ 📦 io_dbio_mad.jar ← 업무 도메인: MAD 관련 IO/DBIO 모듈
┃ ┣ 📦 io_dbio_mcm.jar ← CMS 업무 도메인
┃ ┣ 📦 io_dbio_mvr.jar ← MVR 관련 공통 모듈
┃ ┃┣ 📦 실제 개발 코드 (해당 JAR 내부 구조)
┃ ┣ 📂 nics.mrv.arch.dbio ← 아키텍처 관련 DB 모듈
┃ ┣ 📂 nics.mrv.batch.dbio ← 배치용 DB 접근 모듈
┃ ┣ 📂 nics.mrv.batch.shft ← 배치 스케줄 처리 로직
┃ ┣ 📂 nics.mrv.bizchek.io ← 입력/출력 모델 (DTO)
┃ ┣ 📂 nics.mrv.chek.service ← 업무 로직 처리 (Service 계층)
┃ ┗ 📂 nics.mrv.* ← 업무 모듈 단위로 기능별 구성
dbio, shft, io 등에서도 앞에 역할에 따라 기능별로 나뉘어짐
