- Today
- Total
Notice
Recent Posts
Recent Comments
| 일 | 월 | 화 | 수 | 목 | 금 | 토 |
|---|---|---|---|---|---|---|
| 1 | 2 | 3 | ||||
| 4 | 5 | 6 | 7 | 8 | 9 | 10 |
| 11 | 12 | 13 | 14 | 15 | 16 | 17 |
| 18 | 19 | 20 | 21 | 22 | 23 | 24 |
| 25 | 26 | 27 | 28 | 29 | 30 | 31 |
Tags
- 배열
- 이클립스
- 오라클
- 프로시저
- 클론코딩
- 엘리멘터
- JSP
- PROCEDURE
- spring boot
- dbeaver
- wordpress
- javascript
- 워드프레스
- 티스토리챌린지
- Hostinger
- 오블완
- function
- sql
- iframe
- PLSQL
- Oracle
- 오류해결
- 트러블슈팅
- 환경세팅
- pl/sql
- 문제해결
- 쿼리개선
- 워스프레스
- 함수
- 의존성주입
Archives
개발 공부중
프론트에서 할까 백에서 할까 내가 생각한 기준 정리 본문
화면을 로드했을 때 조회되는 조건의 기본값(하드코딩)을 바꿀 일이 생겼다.
근데 아래 세 가지 수정방법이 있었다.
1. 백단(java)에서 수정
2. 프론트단(jsp)에서 수정
3. 공통으로 처리
나의 경우 보통 다른 사람이 만든 걸 보고 기준을 잡아서 따라했었는데
처리 방법이 다양해서 고민해본 처리 기준 (?)
1. 백단에서 수정해야할 경우
- 같은 api를 여러 화면/엑셀 등에서 같이 사용할 때
- 기본값이 규칙에 가까울 때 (ex 명확한 기준 오늘 날짜로부터 3년전)
=> 조회시 사용자가 값을 바꿀 수 없어서 값이 안전하고 일관됨
=> 화면이 바뀌어도 규칙이 유지됨
=> 단점, 백엔드와 화면 둘 다 수정
2. 프론트단에서 수정해야할 경우
- 화면에서만 바꾸면 될 때
- 서버 로직 변경 없이 빠르게 처리해야할 때
=> 빠르고 영향 범위가 좁음
=> 서버를 안 내려도 됨
=> 단점, api가 다른 곳에서도 쓰이면 기본값이 달라질 수 있음
3. 공통 파일로 처리
- 여러 조회 화면에 똑같이 적용됨
- 공통적인 규칙이 자주 바뀔 수 있을 때
=> 유지보수 편리
이번 경우엔 1번으로 처리했다.
오늘 날짜 값이 controller에 있고 수정코드가 좀 더 짧게 해결됨
날짜 기본값을 controller에서 만들고 프론트에서는 <input value = "${data}"> 로 표시해줬다.
앞으로는 어디를 수정해야 효율적인지 고민하고
다른 사람은 왜 이렇게 했지? 생각해보고
여러방법으로 디버깅도 돌려봐야겠다.
'JAVA' 카테고리의 다른 글
| [JAVA] java.lang.ClassNotFoundException 해결방법(이클립스) (2) | 2024.12.09 |
|---|---|
| [JAVA] java.lang.AbstractMethodError: oracle.jdbc.driver.OracleConnection.isValid(I)Z 에러 해결하기 (0) | 2024.04.03 |
| [eclipse] Show View에 server가 없을 때 목록에 보이게 하는 방법 (0) | 2024.03.29 |
| [JAVA] IndexOutOfBoundsException 에러 해결 (0) | 2024.01.18 |
| [JAVA] Application 객체로 상태값 저장하기(+- 계산기) (0) | 2023.10.19 |
Comments
