여러 쿼리를 하나로 묶어서 DB에 저장해두고, 이름으로 불러 실행하는 기능.

CREATE PROCEDURE USER_INSERT
    @USERNAME NVARCHAR(40),
    @PHONENUMBER NVARCHAR(40),
    @ADDRESSINFO NVARCHAR(2000)
AS
BEGIN
    SET NOCOUNT ON;

    INSERT INTO TBL_USER (USERNO, USERNAME, PHONENUMBER, ADDRESSINFO)
    VALUES (NEXT VALUE FOR USERSEQ, @USERNAME, @PHONENUMBER, @ADDRESSINFO);
END;

-- 실행
EXEC USER_INSERT N'홍길동', N'0101234567', N'서울시 AAA아파트';

• CREATE PROCEDURE : 로직을 DB에 등록 (한 번만)
• EXEC : 등록된 로직을 실행 (여러 번 가능)
• OUTPUT 파라미터를 붙이면 프로시저 내부에서 계산한 값을 호출한 쪽으로 반환 가능

CREATE PROCEDURE USER_SELECT
    @USERNAME NVARCHAR(40),
    @USERCOUNT INT OUTPUT
AS
BEGIN
    SELECT @USERCOUNT = COUNT(*) FROM TBL_USER;
END;

DECLARE @total int;
EXEC USER_SELECT N'홍길동', @total OUTPUT;
SELECT @total;

VIEW와 다른 점: VIEW는 SELECT 결과를 저장한 "가상 테이블" (조회 전용, 파라미터 불가), 프로시저는 파라미터를 받아 INSERT/UPDATE/DELETE까지 자유롭게 실행하는 로직 단위.

변수선언

DECLARE @변수명 데이터타입;
SET @변수명 = 값;
SELECT @변수명 = 컬럼 FROM 테이블;

프로시저 안에서 값을 계산해두고 여러 번 재사용할 때 사용.

CREATE PROCEDURE RESULTDAY_INSERT (@INFO NVARCHAR(200))
AS
BEGIN
    DECLARE @NEXT_RESULTNO INT, @PRICESUM INT;

    SELECT @NEXT_RESULTNO = ISNULL(MAX(RESULTNO)+1, 0) FROM TBL_RESULTDAY;
    SELECT @PRICESUM = SUM(PRICE) FROM TBL_ORDER;

    INSERT INTO TBL_RESULTDAY (RESULTNO, PRICESUM, RESULTDAY)
    VALUES (@NEXT_RESULTNO, @PRICESUM, GETDATE());
END;

예외처리 (TRY-CATCH) + 트랜잭션

문제: 쿼리 여러 개 실행 중 하나가 실패하면 앞부분만 반영되고 뒷부분은 빠지는 반쪽 저장 상태 발생.

해결: TRY-CATCH + TRANSACTION으로 감싸서 전부 성공 아니면 전부 취소.

BEGIN TRY
    BEGIN TRANSACTION;

    INSERT INTO ...;
    INSERT INTO ...;

    COMMIT TRANSACTION;
END TRY
BEGIN CATCH
    ROLLBACK TRANSACTION;
    SELECT ERROR_MESSAGE() AS ErrorMessage;
END CATCH;

• BEGIN TRY 안에서 에러가 나면 즉시 CATCH로 이동
• COMMIT : 전부 성공 시 확정 반영
• ROLLBACK : 하나라도 실패 시 지금까지 실행된 것까지 전부 취소
• 여러 쿼리가 하나의 작업 단위일 때만 트랜잭션 필요, 단일 쿼리면 생략 가능

반복문 (WHILE)

DECLARE @i int;
SET @i = 0;

WHILE (@i < 5)
BEGIN
    INSERT INTO TBL_USER (USERNO, USERNAME, PHONENUMBER, ADDRESSINFO)
    VALUES (@i, N'AAA', N'0100000000', N'서울시 AAA아파트');

    SET @i = @i + 1;
END

카운터 변수를 반복문 안에서 증가시키지 않으면 무한루프 발생.

조건문 (IF, CASE)

IF문: 실행할 쿼리 자체를 조건에 따라 선택.

IF @MODE = 1
BEGIN
    SELECT * FROM TBL_ORDER;
END
ELSE IF (@MODE > 1 AND @MODE <= 3)
BEGIN
    UPDATE TBL_ORDER SET PRICE = PRICE + 300 WHERE USERNO = 2;
END
ELSE
BEGIN
    DELETE FROM TBL_ORDER WHERE PRICE = 1500;
END

CASE문: SELECT 결과의 컬럼 값을 조건에 따라 다르게 표현.

SELECT USERNO, PRODUCTNAME,
    CASE WHEN PRICE > 5000 THEN N'VVIP고객'
         WHEN PRICE > 2000 THEN N'VIP손님'
         WHEN PRICE > 1000 THEN N'A손님'
         ELSE N'일반손님'
    END AS GRADE
FROM TBL_ORDER;

사용자 정의 함수

프로시저와 달리 값 하나를 계산해서 반환하고, SELECT문 안에서 바로 사용 가능.

CREATE FUNCTION textcall (@userno int)
RETURNS int
AS
BEGIN
    DECLARE @result int;
    SELECT @result = SUM(price) FROM TBL_ORDER WHERE USERNO = @userno;
    RETURN @result;
END

-- 사용
SELECT dbo.textcall(1);

BEGIN ~ END

여러 줄의 코드를 하나의 블록으로 묶는 짝꿍 키워드. 다른 언어의 { }와 동일한 역할. 프로시저, 함수, IF, WHILE, TRY/CATCH 어디서나 사용.

데이터베이스 상식

WHERE절에 PK나 UNIQUE 컬럼을 조건으로 쓰거나 먼저 작성하면 인덱스를 활용해 속도가 빨라짐.

SELECT * FROM TBL_USER WHERE USERNO = 1;  -- PK 조건, 좋음

임시테이블

테이블명 앞에 #을 붙이면 임시테이블. 프로시저(BEGIN~END) 안에서만 존재하고 실행이 끝나면 자동 삭제됨. 반복되는 SELECT 결과를 임시로 저장해두고 재사용하면 불필요한 재조회를 줄여 성능 개선 가능.

CREATE TABLE #USERINFO
(
    UserNo int,
    Name VARCHAR(100)
)

INSERT INTO #USERINFO (UserNo, Name)
SELECT 123, '김아름'
UNION SELECT 125, '김길동';

SELECT * FROM #USERINFO WHERE UserNo = 123;

IF EXISTS

데이터 존재 여부에 따라 UPDATE 또는 INSERT를 분기하는 패턴에서 사용. MSSQL 전용 기능.

IF EXISTS (SELECT PRODUCTNO FROM PRODUCT WHERE PRODUCTNAME = @INFO)
BEGIN
    UPDATE PRODUCT SET PRODUCTNAME = @INFO + 'a';
END
ELSE
BEGIN
    INSERT INTO PRODUCT (PRODUCTNO, PRODUCTNAME) VALUES (5, 'a');
END

변수에 담아서 IF로 비교하는 방식보다 간결하고, 있으면 수정·없으면 추가 패턴에서 실무에 자주 쓰임.

1. Data Protection이란?

.NET Core의 Data Protection은 키 관리를 통해 애플리케이션의 민감한 데이터를 보호할 수 있도록 도와주는 기능입니다. 사용자 정보를 암호화/복호화할 때, 그리고 비밀번호를 안전하게 저장할 때 이 모듈을 사용합니다.

1-1. 키 저장 구조

Data Protection을 사용하면 아래 경로에 키 파일이 저장됩니다.

D:\DataProtector\
  └─ key-79b34994-9a62-4481-8149-19ecf7c01bce.xml

GUID 형식의 xml 파일 하나에 아래 정보가 포함되어 있습니다.

• Key Id, Version
• 키 생성일 / 활성화일 / 만료일
• 암호화 유형, 암호 알고리즘 유형
• 암호키 길이, 해시 알고리즘 유형

1-2. AES vs SHA

1-3. CNG 알고리즘

CNG(Cryptography API: Next Generation)는 이름 그대로 차세대 암호화 API로, Data Protection에서 아래와 같은 모드를 선택해서 사용할 수 있습니다.

• CBC (Cipher Block Chaining) — Enums.CryptoType.CngCbc
• GCM (Galois/Counter Mode) — 인증까지 함께 처리 가능한 모드

암호화 유형(CngCbc / CngGcm 등)에 따라 요구되는 조건이 다르며, 대표적으로 아래 조건을 만족해야 합니다.

• 키 길이(Key.Length): 128bit 이상
• 사이즈(size): 64bit 이상

참고로 이 기능은 .NET Core 1.0에서는 지원되지 않고, .NET Core 2.0부터 관리(managed)되기 시작했습니다.

1-4. 실제 사용 코드

aes.EnUserInfo = _protector.Protect(userInfo);       // 암호화
aes.DecUserInfo = _protector.Unprotect(aes.EncUserInfo); // 복호화

암호화 유형에 따라 지정해야 하는 값이 달라지기 때문에, 어떤 CNG 모드를 쓸지 먼저 정하고 그에 맞는 옵션을 설정해야 합니다.

2. Claim 기반 인증(Authentication) & 인가(Authorization)

2-1. 인증 vs 인가

• 인증(Authentication) = "이 사람이 누구인지" 확인하는 것 (신원보증)
• 인가(Authorization) = 인증된 사람이 "무엇을 할 수 있는지" 결정하는 것 (허가승인)

2-2. 핵심 개념

2-3. ClaimType별 용도

로그인 성공 시 사용자 정보를 Claim 형태로 만들어 쿠키에 담아두는데, ClaimType마다 역할이 다릅니다.

Name과 Role은 .NET이 인가 로직에서 직접 인식하는 표준 슬롯이고, UserData는 화면 표시나 별도 로직에서 참조할 부가 정보를 담는 자유 슬롯이라는 점이 핵심입니다.

2-4. 로그인 처리 코드

var identity = new ClaimsIdentity(
    claims: new[] { new Claim(type: ClaimTypes.Name, value: userId) },
    authenticationType: CookieAuthenticationDefaults.AuthenticationScheme
);

await _context.SignInAsync(
    scheme: CookieAuthenticationDefaults.AuthenticationScheme,
    principal: new ClaimsPrincipal(identity: identity),
    properties: null
);

• 신원보증만 필요하면 app.UseAuthentication();
• 신원보증 + 인가까지 필요하면 위처럼 SignInAsync로 Claim을 담아 로그인 처리

3. Password Hasher (비밀번호 해싱)

3-1. Salt란?

같은 비밀번호라도 해시값이 매번 다르게 나오도록 섞어주는 무작위 값입니다. Salt가 없으면 같은 비밀번호를 쓰는 두 사용자의 해시값이 동일해져서 레인보우 테이블 공격에 취약해집니다.

3-2. Iterations (반복 횟수)

비밀번호 해싱 시 같은 연산을 반복하는 횟수로, 보통 10000 / 25000 / 45000 같은 값을 사용합니다.

• 반복 횟수가 많을수록 해시 계산 시간이 늘어나 무차별 대입 공격에 걸리는 시간이 크게 늘어남
• 다만 서버 부하도 함께 커지므로, 보안성과 성능 사이 균형점을 고려해서 값을 정해야 함

정리

오늘은 .NET Core에서 데이터를 안전하게 다루는 두 축을 학습했습니다.

1. Data Protection: 데이터 자체를 암호화/복호화하는 방법 (AES, CNG 모드)
2. Claim 인증/인가: 로그인한 사용자가 누구인지, 무엇을 할 수 있는지 판단하는 방법
3. Password Hasher: 비밀번호를 안전하게 저장하기 위한 Salt와 Iterations 개념

다음에는 이 개념들이 실제 프로젝트 코드에서 어떻게 조합되어 쓰이는지 더 파봐야겠습니다.><

오래된 강의(2017~2019년) 따라서 .NET Core 프로젝트 세팅하다가 만난 에러들 정리. 강의는 EF Core 초기 버전 + .NET Framework 시절 문법이라, 지금(.NET 8, EF Core 8) 기준으로 옮기면서 겪은 문제들을 기록해둔다.

1. DbContext가 여러 개일 때 - -Context 필수

프로젝트에 CodeFirstDbContext, DBFirstDbContext 두 개를 등록해두면, 마이그레이션 명령어를 칠 때마다 아래 에러가 뜬다.

More than one DbContext was found. Specify which one to use.
Use the '-Context' parameter for PowerShell commands...

해결은 간단하다. Add-Migration, Update-Database 어떤 명령어든 -Context를 명시해주면 됨.

Add-Migration AddingUserTable -Context CodeFirstDbContext -Project NetCore.Services
Update-Database -Context CodeFirstDbContext -Project NetCore.Services

2. 마이그레이션 파일이 엉뚱한 프로젝트에 생성될 때

-Project NetCore.Migrations로 지정했는데, 실제로는 NetCore.Services에 마이그레이션 폴더가 생기는 현상을 겪었다.

Your target project 'NetCore.Migrations' doesn't match your migrations assembly 'NetCore.Services'.

원인은 Program.cs에서 MigrationsAssembly("NetCore.Migrations")를 지정해도, 프로젝트 안에 IDesignTimeDbContextFactory를 구현한 클래스가 있으면 EF 툴이 Program.cs를 무시하고 그 팩토리를 최우선으로 사용한다는 것.

public class CodeFirstDBContextFactory : IDesignTimeDbContextFactory<CodeFirstDbContext>
{
    public CodeFirstDbContext CreateDbContext(string[] args)
    {
        var optionsBuilder = new DbContextOptionsBuilder<CodeFirstDbContext>();
        optionsBuilder.UseSqlServer(
            connectionString,
            mig => mig.MigrationsAssembly("NetCore.Migrations")); // 여기 추가해야 함
        return new CodeFirstDbContext(optionsBuilder.Options);
    }
}

팩토리가 있는 경우엔 팩토리 안의 UseSqlServer 옵션에도 똑같이 MigrationsAssembly를 지정해줘야 원하는 프로젝트로 마이그레이션 파일이 떨어진다. Program.cs 설정만 믿고 있으면 계속 삽질하게 됨.

3. Design-time factory가 중복되면 생기는 문제

프로젝트 두 곳에 각각 IDesignTimeDbContextFactory를 구현한 클래스가 있으면, EF 툴이 어느 걸 써야 할지 애매해지면서 계속 엉뚱한 프로젝트를 잡는다. 팩토리는 딱 하나만 유지하는 게 정신건강에 이롭다.

4. SQL Server 연결 시 SSL 인증서 에러

로컬 SQL Server(Express)에 접속할 때마다 나던 에러.

서버에 연결했지만 로그인하는 동안 오류가 발생했습니다.
(provider: SSL 공급자, error: 0 - 신뢰되지 않은 기관에서 인증서 체인을 발급했습니다.)

최근 SQL Server가 기본적으로 암호화 연결을 요구하도록 바뀌었는데, 로컬 개발용 서버엔 정식 SSL 인증서가 없어서 나는 에러다. 연결 문자열에 옵션 하나만 추가하면 해결된다.

Server=localhost\SQLEXPRESS;Database=CodeFirstDB;User Id=coreuser;Password=corepwd;Encrypt=Optional;TrustServerCertificate=True;

SSMS로 접속할 때도 마찬가지로 연결 창에서 "서버 인증서 신뢰" 체크박스를 켜주면 된다.

5. Startup.cs vs Program.cs (.NET 8 minimal hosting)

강의는 Startup.cs에 ConfigureServices / Configure를 나눠 쓰는 옛날 방식인데, .NET 8은 Program.cs 하나로 통합된 minimal hosting 방식을 쓴다. 대응 관계는 이렇게 정리하면 편하다.

강의에서 Startup.cs 코드가 나오면, "이게 서비스 등록이냐 미들웨어 파이프라인이냐"만 구분해서 위/아래 절반으로 나눠 옮기면 됨.

6. builder.Build() 이후에 builder.Services 건드리면 안 됨

무심코 코드 복붙하다가 var app = builder.Build(); 아래에 builder.Services.AddDbContext(...)를 또 넣어서 에러 났었다. Build() 시점 이후로는 서비스 컨테이너가 이미 확정된 상태라, 그 이후엔 절대 builder.Services를 추가로 건드리면 안 된다.

7. FromSql → FromSqlRaw / FromSqlInterpolated

EF Core 3.0부터 FromSql(string sql)이라는 메서드 자체가 사라졌다. 2017~2019년 강의 코드엔 그대로 남아있어서 컴파일 에러가 남.

// 옛날 (지금은 존재하지 않는 메서드)
_context.Users.FromSql("SELECT * FROM User")

// 지금 - 변수 없는 순수 SQL 문자열
_context.Users.FromSqlRaw("SELECT * FROM User")

// 지금 - SQL 안에 변수가 들어가는 경우 (SQL Injection 방지용 파라미터화)
_context.Users.FromSqlInterpolated($"SELECT * FROM User WHERE UserId = {userId}")

이름만 바뀐 게 아니라, Interpolated 계열은 문자열 보간을 자동으로 파라미터화해서 SQL Injection을 막아주는 안전장치가 추가된 거다. 변수가 없으면 Raw, 있으면 Interpolated 쓰면 됨.

8. 생성자 이름은 클래스 이름과 정확히 같아야 함

복붙하다가 흔히 나는 실수. DBFirstDbContext 클래스인데 생성자 이름이 CodeFirstDbContext로 남아있으면 컴파일러가 "메서드에는 반환 형식이 있어야 합니다"라는, 원인 파악하기 애매한 에러를 던진다.

public class DBFirstDbContext : DbContext
{
    // 클래스 이름이랑 다르면 생성자가 아니라 이상한 메서드로 인식됨
    public CodeFirstDbContext(DbContextOptions<CodeFirstDbContext> options) : base(options) { } // ❌

    public DBFirstDbContext(DbContextOptions<DBFirstDbContext> options) : base(options) { } // ✅
}

9. public 클래스는 인터페이스도 public이어야 함

CS0060: 일관성 없는 액세스 가능성: 'IUser' 기본 클래스가 'UserService' 클래스보다 액세스하기 어렵습니다.

public class UserService : IUser인데 interface IUser가 public이 아니면 나는 에러. C#은 public 클래스가 구현/상속하는 타입도 최소한 같은 수준으로 공개되어 있어야 한다는 규칙이 있다. interface IUser → public interface IUser로 고치면 해결.

오늘 삽질 요약하면, 결국 대부분 "강의는 5~7년 전 버전, 지금은 최신 버전"이라는 시차에서 오는 문제였다. 에러 메시지를 찬찬히 읽으면 대부분 원인이 메시지 안에 다 적혀있다는 것도 새삼 느낌.

C# (언어)
  → .NET (플랫폼/런타임, 예전엔 .NET Core라고 불림)
    → ASP.NET Core (그 위에서 웹 앱/API 만드는 프레임워크)

짧고, 간단하게 설명하자면 이렇다!

1단계: 개념 이해

인터페이스(Interface)

Interface에 대해 알아보자! 먼저 이 예시코드를 보며 이해긔긔!!!

public interface IUserService
{
    void CreateUser(string name);
}

public class UserService : IUserService
{
    public void CreateUser(string name) { /* 실제 DB 저장 로직 */ }
}

_이 클래스는 이런 기능을 반드시 가지고 있어야 한다_이다.

이 코드를 보면서 제일 궁금했던 부분은 UserService, IUserService의 사이에 있는 : 이다. " : "는 쉽게 설명하자면 implements를 의미한다.

상속(inheritance): 부모 클래스의 실제 동작(코드)까지 물려받음 구현(interface/implements): 인터페이스가 정해둔 "규칙(메서드 이름만)"만 따르고, 실제 코드는 직접 다 채워야 함

: 기호를 C#에서는 상속(extends)과 구현(implements) 둘 다에 씁니다. 자바처럼 나눠 쓰지 않아요.

컨트롤러는 IUserService라는 "약속"만 알고 있고, 실제 구현체(UserService)가 뭔지는 몰라도 됩니다. 나중에 UserService를 다른 걸로 바꿔도 컨트롤러 코드는 안 건드려도 돼요. → 이게 DI(의존성 주입)의 기초가 됩니다.

인터페이스는 "이런 메서드가 있어야 한다"고 강제만 하고, 실제로 어떻게 동작할지는 구현하는 클래스가 알아서 채워요 :)

2. async/await

async/await는 시간이 걸리는 작업(DB 조회, API 호출 등)을 기다리는 동안 서버가 놀지 않고 다른 요청을 처리하게 해주는 문법이다.

//예시 소스
public async Task<User> GetUserAsync(int id)
{
    var user = await _dbContext.Users.FindAsync(id);  
    return user;
}

Task는 "User가 나중에 도착할 거야"라는 포장 상자이다.

이해하기 쉽게 설명하자면, user로 반환한 값을 포장 상자 안에 넣어 저장이 되는 것이다.

async: 이 메서드는 비동기로 동작한다고 표시 await는 "DB가 응답 줄 때까지 여기서 기다릴게 근데 기다리는 동안 서버는 다른 손님(요청) 받아도 돼"라는 뜻이다.

3. LINQ

한 줄 정의: 컬렉션(List, DB 데이터 등)을 SQL처럼 필터링/조회하는 문법.

List<int> numbers = new List<int> { 1, 2, 3, 4, 5 };

var evens = numbers.Where(n => n % 2 == 0);       // 짝수만: [2, 4]
var first = numbers.FirstOrDefault(n => n > 3);    // 3보다 큰 첫 값: 4
var doubled = numbers.Select(n => n * 2);          // 각 값 2배: [2,4,6,8,10]

DB를 할 때도

var user = await _dbContext.Users.FirstOrDefaultAsync(u => u.Email == email);

Where: 조건에 맞는 것만 골라내기(필터링) FirstOrDefault: 조건에 맞는 첫 번째 값 하나만 가져오기 (없으면 null 또는 기본값 반환) Select: "검색"이라기보다는 모양을 바꿔서 뽑아내기(변환)

4. DI

  //예시소스
builder.Services.AddScoped<IUserService, UserService>();

// 컨트롤러에서는 그냥 받아서 씀
public class UserController : ControllerBase
{
    private readonly IUserService _userService;

    public UserController(IUserService userService) {
        _userService = userService;
    }
}

의 소스 중에서

builder.Services.AddScoped<IUserService, UserService>();

IUserService라는 계약서가 필요할 때는 UserService라는 실제 구현체를 갖다 써라! AddScoped는 "이 객체를 웹 요청 하나당 1개씩 새로 만들어서 써라"는 규칙(생명주기)을 정하는 것.

public UserController(IUserService userService)
--> "나 IUserService 필요해요!" 라고 요청

이렇게 생성자에 써두기만 해도 ASP.NET Core가 알아서 "아까 등록해둔 UserService를 여기 꽂아줄게"라고 자동으로 넣어준다.

SELECT PT_NAME,PT_NO,GEND_CD,AGE, COALESCE(TLNO,"NONE") AS TLNO FROM PATIENT WHERE AGE<=12 AND GEND_CD='W' ORDER BY AGE DESC, PT_NAME ASC;

여기 조건을 딱 정리하자면

1. 12세 이하만(AGE<=12)
2. 여자환자(W)
3. 환자이름, 환자번호, 성별 코드, 나이, 전화번호 조회
4. 전화번호가 (null)값이라면 'NONE' 출력
5. 우선순위 (1) 나이 내림차순 (AGE DESC), (2) 환자 이름 오름차순(PT_NAME ASC)

여기서 가장 어려웠던 부분! Update나 insert 부분은 is not null이나 is null을 사용해서 null 값이 있는 부분을 판별하면 되는데, SELECT 문은 처음이었습니다. 그래서 다른 개발자 분들의 소스를 보고, 참고하여 작성했습니다!

COALESCE란?

영어 단어 coalesce는 원래 "합쳐지다"라는 뜻이며 데이터베이스에서는 NULL 값을 다른 대체 값으로 바꾸거나 여러 컬럼을 병합하여 유효한 값을 찾을 때 사용합니다!

요즘 코테 하면 level 2보다 1이 어려운 것 같아요,,,

SELECT ANIMAL_ID, NAME FROM ANIMAL_INS WHERE INTAKE_CONDITION != 'Aged' ORDER BY ANIMAL_ID ASC;

젊은 동물을 어떻게 판별하지? 했는데 db 설계도를 먼저 코드 실행으로 알아보니 INTAKE_CONDITION에 'Aged'가 젊지 않은 동물을 표현하는 것 같아 INTAKE_CONDITION에 Aged라면? 그거 빼고! 라는 출력을 넣었고, 이때 결과는 아이디 순이라는 말은 정렬 즉,

ORDER BY

를 사용하라는 것이기 때문에, ANIMAL_ID 오름차순으로 정렬했습니다!

피드백 ture. 허용합니다. :)

select sum(PRICE) as TOTAL_PRICE FROM ITEM_INFO WHERE RARITY='LEGEND';

sum으로 총합을 구하고 이떄 컬렴명은 'TOTAL_PRICE'이기 때문에, AS로 컬럼명을 수정한다. 또한 테이블에서 희귀도가 'LEGEND'만 조회하라고 했기 때문에 WHERE문에 RARITY가 'LEGEND'것 만 출력한다.

정답

SELECT FLAVOR FROM FIRST_HALF ORDER BY TOTAL_ORDER DESC, SHIPMENT_ID ASC;

총주문량(TOTAL_ORDER)은 내림차순으로 DESC, 출하번호(SHIPMENT_ID)은 오름차순 ASC으로 정렬된다.

📚 수행평가 범위 정리

Ⅰ. VIEW(뷰) ⭐⭐⭐⭐⭐

1. View란?

View = SELECT문의 결과를 테이블처럼 사용할 수 있도록 만든 가상의 테이블

• 실제 데이터를 저장하지 않음
• 기존 테이블을 기반으로 만들어짐
• 실제로는 SELECT문을 저장
• 기본 테이블의 데이터를 보여주는 창(window) 역할

핵심 암기

View는 실제 테이블이 아니라 SELECT 결과를 테이블처럼 사용하는 가상 테이블이다.

2. View 생성

CREATE VIEW V_커피메뉴 AS
SELECT DRINK_ID AS 음료번호,
       DRINK_NAME AS 음료이름,
       PRICE AS 가격
FROM DRINK
WHERE CATEGORY = '커피';

개념

CREATE VIEW → View 생성
AS → 뒤의 SELECT문을 View의 정의로 사용

3. View 조회

SELECT *
FROM V_커피메뉴;

View를 만든 뒤에는 일반 테이블처럼 SELECT할 수 있음.

SELECT *
FROM V_커피메뉴
WHERE 가격 <= 3000;

Ⅱ. View의 특징 ⭐⭐⭐⭐⭐

PDF에서 강조하는 부분.

① 실제 데이터를 저장하지 않음

View에는 데이터를 복사해서 저장하는 것이 아니라 SELECT문이 저장됨.

② SELECT 결과를 테이블처럼 사용

SELECT *
FROM V_커피메뉴;

③ 기본 테이블이 변경되면 View 결과도 변경

View가 DRINK를 기반으로 만들어졌다면 DRINK의 데이터가 바뀔 경우 View의 결과도 바뀜.

④ 기본 테이블 대신 View를 통해 조회 가능

필요한 데이터만 View로 만들어 사용자에게 제공할 수 있음.

⑤ 데이터 보안

기본 테이블의 모든 정보를 보여주지 않고 원하는 컬럼이나 데이터만 View로 제공할 수 있음.

PDF에서는 View를 데이터 보안 측면에서 활용하고, 원하는 내용만 보여줄 수 있다고 설명함.

Ⅲ. View의 장점 ⭐⭐⭐⭐⭐

① 복잡한 질의를 단순하게 표현

복잡한 SQL을 View로 미리 만들어두면:

SELECT *
FROM V_주문영수증;

처럼 간단하게 사용할 수 있음.

PDF에서도 복잡한 SQL을 미리 정의하고 이후 간단한 SQL문으로 조회할 수 있다고 설명함.

② 특정 데이터만 사용자에게 보여줌

예:

CREATE VIEW V_커피메뉴 AS
SELECT DRINK_ID, DRINK_NAME, PRICE
FROM DRINK
WHERE CATEGORY = '커피';

→ DRINK의 모든 정보를 보여주지 않고 커피 메뉴만 제공

③ 데이터 독립성

프로그램에서 복잡한 원본 테이블 구조를 직접 다루지 않고 View를 사용할 수 있음.

즉,

기본 테이블
↓
View
↓
프로그램

형태로 사용할 수 있음.

PDF에서도 View의 장점으로 데이터 독립성을 제시함.

Ⅳ. View의 단점 ⭐⭐⭐

PDF에서 나오는 핵심:

① 모든 View가 갱신 가능한 것은 아님

② 기본 테이블보다 성능이 떨어질 수 있음

View를 사용할 때 DBMS가 View의 정의를 확인하고 기본 테이블을 조회하는 과정이 필요함.

Ⅴ. 갱신 불가능한 View ⭐⭐⭐⭐⭐

어떤 View든 UPDATE가 되는 것은 아님.

PDF에서 제시한 대표적인 갱신 불가능 조건:

① 집계 함수 SUM, AVG
② GROUP BY
③ JOIN
④ 기본키 없음

예시

CREATE VIEW V_지점별매출 AS
SELECT C.CAFE_LOCATION,
       SUM(D.PRICE * O.QTY) AS 총매출
FROM CAFE C
JOIN DRINK D
ON C.CAFE_ID = D.CAFE_ID
JOIN ORDERS O
ON D.DRINK_ID = O.DRINK_ID
GROUP BY C.CAFE_LOCATION;

이 View에는

SUM
JOIN
GROUP BY

가 있기 때문에 갱신하기 어려움.

Ⅵ. View 삭제 ⭐⭐

DROP VIEW V_커피메뉴;

중요

View를 삭제해도 기본 테이블에는 영향을 주지 않음.

즉,

DROP VIEW
↓
View만 삭제
↓
DRINK 테이블은 그대로

Ⅶ. 시스템 카탈로그 ⭐⭐⭐⭐⭐

1. 시스템 카탈로그란?

데이터베이스의 구조와 객체 정보를 저장하는 메타데이터

메타데이터

데이터에 대한 데이터

예를 들어 실제 데이터가:

메가커피
메가리카노
2000원

이라면 메타데이터는:

DRINK라는 테이블이 존재한다.
DRINK_ID라는 컬럼이 있다.
DRINK_ID의 자료형은 NUMBER다.

같은 데이터베이스의 구조 정보임.

Ⅷ. 시스템 카탈로그에 저장되는 정보 ⭐⭐⭐

PDF 기준으로:

• 테이블 정보
• 컬럼 정보
• 데이터 타입
• 인덱스
• 사용자 정보
• 접근 권한

등을 저장함.

Ⅸ. 시스템 카탈로그의 역할 ⭐⭐⭐⭐

① 데이터베이스 구조 관리

테이블, 컬럼, 데이터 타입 등의 구조 정보를 저장.

② 사용자 권한 관리

사용자마다 어떤 테이블을 조회하거나 수정할 수 있는지 관리.

③ 질의 최적화 지원

DBMS가 SQL을 실행할 때 테이블 구조나 인덱스 정보를 확인해서 질의 처리에 활용.

④ 데이터베이스 검색 지원

테이블 등의 정보를 조회할 수 있음.

Ⅹ. 시스템 카탈로그의 특징 ⭐⭐⭐⭐

① DB 내부에 존재하는 특수한 테이블

② DBMS가 자동으로 관리

테이블을 만들거나 삭제하면 시스템 카탈로그도 자동으로 변경됨.

③ 사용자가 직접 수정할 수 없음

데이터베이스 구조를 관리하는 중요한 정보이기 때문에 직접 수정할 수 없음.

Ⅺ. 시스템 카탈로그 조회 쿼리 ⭐⭐⭐⭐⭐

① 내가 만든 테이블 목록

SELECT TABLE_NAME
FROM USER_TABLES;

개념

USER_TABLES

→ 사용자가 만든 테이블 정보

② 특정 테이블의 컬럼 정보

SELECT COLUMN_NAME,
       DATA_TYPE,
       DATA_LENGTH,
       NULLABLE
FROM USER_TAB_COLUMNS
WHERE TABLE_NAME = 'DRINK';

개념

USER_TAB_COLUMNS

→ 테이블의 컬럼 구조 확인

⚠️ TABLE_NAME = 'DRINK'처럼 테이블 이름은 대문자로 작성.

③ 제약조건 목록

SELECT TABLE_NAME,
       CONSTRAINT_NAME,
       CONSTRAINT_TYPE
FROM USER_CONSTRAINTS
ORDER BY TABLE_NAME;

개념

USER_CONSTRAINTS

→ 제약조건 정보 확인

예:

PRIMARY KEY
FOREIGN KEY
CHECK

④ View 목록

SELECT VIEW_NAME
FROM USER_VIEWS;

개념

USER_VIEWS

→ 내가 만든 View 목록 확인

⑤ View의 실제 정의

SELECT VIEW_NAME, TEXT
FROM USER_VIEWS
WHERE VIEW_NAME = 'V_지점별매출';

개념

TEXT

→ 해당 View를 만들 때 사용한 SELECT문 확인

Ⅻ. 실습 SQL에서 같이 나오는 기본 개념

PDF가 직접적으로 다루는 핵심은 View와 시스템 카탈로그지만, 네 수행평가 실습에서는 그걸 만들기 위해 아래 SQL 개념도 사용하고 있음.

SELECT

SELECT DRINK_NAME, CATEGORY, PRICE
FROM DRINK;

→ 데이터 조회

WHERE

WHERE PRICE >= 4000

→ 조건에 맞는 데이터 조회

LIKE

WHERE DRINK_NAME LIKE '%라떼%'

→ 특정 문자열 검색

ORDER BY

ORDER BY PRICE DESC;

→ 결과 정렬

JOIN

JOIN DRINK D
ON C.CAFE_ID = D.CAFE_ID

→ 여러 테이블 연결

집계함수

SUM()
AVG()
MAX()
MIN()
COUNT()

→ 여러 데이터를 하나의 값으로 계산

GROUP BY

GROUP BY C.CAFE_LOCATION

→ 특정 기준으로 데이터를 그룹화

HAVING

HAVING SUM(D.PRICE * O.QTY) >= 5000

→ 그룹화된 결과에 조건 적용

서브쿼리

WHERE PRICE = (
    SELECT MAX(PRICE)
    FROM DRINK
);

→ SQL 안에 SQL을 넣어서 결과를 이용

🎯 진짜 수행평가용 핵심 구조

시험 전에 이 구조로 머릿속에 넣으면 돼.

[VIEW]
│
├─ 정의
│  └─ SELECT 결과를 테이블처럼 사용하는 가상 테이블
│
├─ 특징
│  ├─ 실제 데이터 저장 X
│  ├─ SELECT문 저장
│  ├─ 기본 테이블 변경 → View 결과 변경
│  └─ 필요한 데이터만 보여줄 수 있음
│
├─ 장점
│  ├─ 복잡한 질의 단순화
│  ├─ 데이터 보안
│  └─ 데이터 독립성
│
├─ 단점
│  ├─ 모든 View 갱신 가능 X
│  └─ 성능 저하 가능
│
├─ 갱신 불가능
│  ├─ SUM / AVG
│  ├─ GROUP BY
│  ├─ JOIN
│  └─ 기본키 없음
│
└─ SQL
   ├─ CREATE VIEW
   ├─ SELECT FROM VIEW
   └─ DROP VIEW


[시스템 카탈로그]
│
├─ 정의
│  └─ DB 구조와 객체 정보를 저장하는 메타데이터
│
├─ 저장 정보
│  ├─ 테이블
│  ├─ 컬럼
│  ├─ 데이터 타입
│  ├─ 인덱스
│  ├─ 사용자
│  └─ 권한
│
├─ 특징
│  ├─ DBMS가 자동 관리
│  └─ 사용자가 직접 수정 X
│
└─ SQL
   ├─ USER_TABLES
   ├─ USER_TAB_COLUMNS
   ├─ USER_CONSTRAINTS
   └─ USER_VIEWS

디스크 스케줄링 정리

오늘은 디스크 스케줄링의 대표적인 알고리즘인 FCFS, SSTF, SCAN, C-SCAN을 문제를 직접 풀면서 학습했다.

1. FCFS (First Come First Served)

요청이 들어온 순서 그대로 처리하는 방식이다.

예를 들어 시작 위치가 53이고 Queue가 25, 130, 10이라면:

53 → 25 → 130 → 10

각 요청까지의 이동거리를 계산하여 총 헤드 이동 거리를 구한다.

핵심: Queue 순서 그대로

2. SSTF (Shortest Seek Time First)

현재 헤드 위치에서 가장 가까운 요청부터 처리하는 방식이다.

예를 들어 현재 위치가 53이라면 각 요청과의 거리를 비교해서 가장 가까운 요청을 선택한다.

53 → 55

이후 현재 위치가 55가 되었으므로 다시 남은 요청들과의 거리를 비교한다.

⚠️ 동률 주의

현재 위치가 55이고 남은 요청이 25, 85라면:

• 55 → 25 = 30
• 55 → 85 = 30

둘의 거리가 같기 때문에 동률(tie)이 발생한다.

따라서 문제나 수업에서 동률 처리 기준을 제시했는지 확인해야 한다. 별도의 기준이 없다면 어느 쪽을 먼저 처리할지 답이 하나로 고정되지 않을 수 있다. 거리가 같을 때는 헤드의 물리적 무리를 줄이기 위해 기존 진행 방향을 유지하는 것이 기본 표준 규칙입니다..

핵심: 현재 위치에서 가장 가까운 요청을 선택 + 동률 처리 규칙 확인

3. SCAN

엘리베이터처럼 한 방향으로 이동하면서 요청을 처리하고, 디스크의 끝까지 이동한 후 방향을 바꾸는 방식이다.

예를 들어 53에서 시작하고 0 방향으로 먼저 이동한다면:

53 → 18 → 9 → 0 → 72 → 120 → ...

여기서 중요한 것은 요청 중 가장 작은 값인 9까지만 가는 것이 아니라 디스크의 끝인 0까지 이동한다는 것이다.

반대로 199 방향이라면 199까지 이동한 후 방향을 바꾼다.

핵심: 한 방향 → 끝까지 → 방향 전환

4. C-SCAN

SCAN과 비슷하지만 한 방향으로만 요청을 처리한다.

예를 들어 53에서 0 방향으로 시작한다면:

53 → 18 → 9 → 0 → 199 → 185 → 150 → ...

0에 도착하면 방향을 바꾸어 처리하는 것이 아니라 반대쪽 끝인 199로 이동한 후 다시 같은 방향으로 처리한다.

핵심: 한 방향 → 끝까지 → 반대쪽 끝으로 이동 → 다시 같은 방향

5. 네 가지 알고리즘 비교

오늘의 핵심

디스크 스케줄링 문제는 단순히 처리 순서만 찾는 것이 아니라 각 이동 거리를 계산하여 총 이동 거리까지 구하는 것이 중요하다.

특히 SCAN과 C-SCAN은 디스크의 끝(0 또는 199)을 반드시 고려해야 하며, SSTF에서 같은 거리가 나오는 경우 동률 처리 기준을 확인해야 한다.

정답

SELECT DR_NAME,DR_ID,MCDP_CD,HIRE_YMD FROM DOCTOR WHERE MCDP_CD='CS' OR MCDP_CD='GS' ORDER BY HIRE_YMD DESC, DR_NAME ASC;

WHERE 절로 CS와 GS 둘 중 하나를 고르고,고용일자는 내림차순으로, 이름은 오름차순

정답

SELECT NAME FROM ANIMAL_INS WHERE DATETIME=(SELECT MIN(DATETIME) FROM ANIMAL_INS);

이번 문제에는 서브쿼리를 활용하면 더 빠르게 구현할 수 있을 것 같아 서브쿼리로 구현해보았습니다 :)

코드 답

SELECT MAX(PRICE) AS MAX_PRICE FROM PRODUCT;

MAX로 가장 높은 판매가를 찾아내고, AS로 컬럼명을 수정한다.

SELECT COUNT(*) AS count FROM ANIMAL_INS;

이미 동물 보호소에 들어온 동물들의 정보이기 때문에 릴레이션(테이블)의 튜플(행)을 개수를 세도록 구현하였습니다 :)

SQL 답

SELECT ANIMAL_ID, NAME FROM ANIMAL_INS WHERE NAME LIKE '%el%' AND NAME LIKE '%EL%' AND ANIMAL_TYPE='Dog' ORDER BY NAME, ANIMAL_ID;

이름에 el이 들어있는 걸 LIKE으로 찾고 %el으로 하면 앞에 뭐가 오든 뒤에 el만 성립이 된다면 true. %el%으로 하면 el 문자 앞 뒤에 뭐가 오든 el만 있으면 성립이 된다. 하지만 LIKE는 대소문자를 구분하기 때문에 EL과 el을 넣었다.

그리고 동물의 타입은 dog이여야 하므로 Dog으로 저장되어있는 동물만 조회를 할 수 있게 구현하였습니다 :)

다른 분들의 풀이를 보면 LOWER(NAME)으로 LIKE를 한 번만 사용하는 가독성을 만들었지만 아직은 활용해보지 않았던 문법이라서 먼저 저의 방식대로 구현해보았습니다:) 감사합니다

SQL 답

-- 코드를 입력하세요
SELECT NAME,DATETIME FROM ANIMAL_INS ORDER BY ANIMAL_ID DESC;

원하는 출력 NAME,DATETIME을 작성하고 ANIMAL_INS에서 ANIMAL_ID을 내림차순으로 정렬하게 만들면 역순이 된다.

SQL 답

-- 코드를 입력하세요
SELECT ANIMAL_ID, NAME FROM ANIMAL_INS WHERE INTAKE_CONDITION LIKE 'Sick';

원하는 출력 ANIMAL_ID, NAME을 ANIMAL_INS테이블에서 INTAKE_CONDITION Sick 아픈 동물만 출력하는 SQL 문을 만들었습니다 :)

학교에서 MySQL 수업을 듣는데 코테로 실습을 해봤는데 생각보다 쉬워서 놀랬다. AI 없이도 코딩할 수 있음에 뿌듯함을 느꼈습니다 ><

PRIMARY KEY (기본키)

• 중복 불가
• NULL 불가
• 테이블에서 데이터를 구별하는 번호

  CREATE TABLE BOOK(
    BNO NUMBER PRIMARY KEY
  );

  FOREIGN KEY (외래키)

  다른 테이블의 기본키를 참조

  BNO NUMBER,
  FOREIGN KEY(BNO) REFERENCES BOOK(BNO)

  부모의 번호만 자식에서 사용할 수 있다.

ON DELETE CASCADE

< 부모 삭제하면 자식도 같이 삭제 >

FOREIGN KEY(BNO)
REFERENCES BOOK(BNO)
ON DELETE CASCADE;

DEFAULT

값을 안 넣으면 자동 입력

RDATE DATE DEFAULT SYSDATE

UNIQUE

SHOP_NAME VARCHAR2(50) UNIQUE

Null은 가능하지만 중복은 금지

테이블에 값 추가

INSERT

모든 컬럼 입력

INSERT INTO BOOK
VALUES(1,'SQL','홍길동',20000);

일부 컬럼만

INSERT INTO BOOK(BNO,TITLE)
VALUES(2,'데이터베이스');

테이블 값 조회

SELECT *
FROM BOOK;

전체 조회가 아닌 원하는 값만 조회하고 싶다면 * => 대신 일부 컬럼을 작성

WHERE 조건

같다 표현

WHERE PRICE=10000

크기 비교

WHERE PRICE>=20000

BETWEEN

WHERE PRICE
BETWEEN 10000 AND 20000

범위 측정할 때 자주 사용

IN

여러개의 카테고리 중에 속하는 애들만 조회

WHERE CATEGORY
IN('치킨','커피')

LIKE

% <- 앞뒤 뭐가 있든 상관 없음 __ <-갯수가 정해져있음

정렬

오름차순

ORDER BY PRICE ASC;

내림차순

ORDER BY PRICE DESC;

JOIN

SELECT R.SNAME,
       B.TITLE
FROM RENTAL R
JOIN BOOK B
ON R.BNO=B.BNO;

집계함수

• COUNT(개수)
• SUM(합계)
• AVG(평균)
• MAX(최대)
• MIN(최소)

GROUP BY

같은 것끼리 묶기

SELECT CATEGORY,
COUNT(*)
FROM SHOP
GROUP BY CATEGORY;

HAVING

GROUP BY 이후 조건

GROUP BY CATEGORY
HAVING COUNT(*)>=2;

**WHERE → 일반 조건

HAVING → 집계 조건**

UPDATE 수정

UPDATE BOOK
SET PRICE=15000
WHERE BNO=1;

DELETE

DELETE
FROM BOOK
WHERE BNO=1;

WHERE 안 쓰면 전부 삭제

ALTER TABLE

테이블 수정

ALTER TABLE MOVIE
MODIFY GENRE VARCHAR2(100);

서브쿼리

쿼리 안의 쿼리

SELECT *
FROM BOOK
WHERE PRICE=
( SELECT MIN(PRICE) FROM BOOK );

FETCH FIRST

상위 N개 ex) Top5 가져오기

ORDER BY PRICE DESC
FETCH FIRST 5 ROWS ONLY;

1. 자바 기반 응용 프로그램 개발 프레임워크
2. 2003년 6월 Rod Johnson 발표
3. 모든 Java 애플리케이션 개발 이용 ㄱㄴ
4. Java EE 기반 웹 애플리케이션 개발

⇒ Spring Framework는 기반 기술, Spring Boot는 Spring을 더 쉽고 빠르게 쓰게 해주는 도구다.

Spring Framework

• 경량 컨테이너

• POJO 방식

• IoC 지원 (제어의 역전) <개념>

  • 객체생성이나 관리 그런 부분이 Spring이 다 해줌. 개발자는 그걸 요청하는 코딩만 하면 되는 것. (예전에는 객체생성이나 관리까지 개발자가 함)

  • 제어의 역전

  • 스프링 컨테이너 객체 생성

  • 개발 효율성(up) 유지보수 용이

  • *<주요 특징>**

    → 객체 생성, 초기화 자동 관리

    → 의존 관계를 자동으로 연결 편리 제공

    → 유연한 구조로 설정 변경 용이

    → 낮은 결합도로 유지보수 용이

    ⇒IoC는 매니저(소속사)가 있다는 느낌 (직접스케줄관리X)

• DI 지원 (의존성 주입)

  1) 생성자 DI (Constructor DI) 2) setterDI

• AOP 지원

  공통으로 들어가는 것을 (횡단관심) 횡단관심은 : 공통기능 → spring이 관리함 필요한 핵심 기능 (종단관심) 종단관심: 핵심기능 → 개발자가 관리함.

다형성

자바에서의 모든 객체는 부모클 참조변수나 구현한 인터페이스 변수에 담을 수 있다. ⇒ 이러한 참조변수를 통해 메서드를 호출하면 오버라이딩된 메서드가 호출된다.

Spring Framework 장점

• 코드량 감소
• 생산성 향상
• 유지보수 쉬움
• 의존성 관리 편함 (DI)
• 재사용성 높음

빌드도구

• 소스코드를 컴파일부터 배포까지의 전 과정을 자동으로 실행시켜주는 도구*

1. 빌드 자동화는 소프트웨어 개발의 효율성을 높이는 중요한 과정
2. 필요한 라이브러리를 다운로드
3. 코드 컴파일, 자동으로 테스트 실행 후
4. 실행 파일을 생성, 배포 5. Maven(pom.xml) / gradle (build.gradle)

스프링은 요리사 개발자는 사장넴

spring application에 필요한 라이브러리: spring-context

스프링의 maven 라이브러리들이 모아져 있는 곳에서 다운받아야함.

Java에서 class 에서 활용되는 get set이 Spring에서는 getBean()이런 느낌으로 활용이 된다.

Maven 핵심 한 줄

XML 기반으로 프로젝트 빌드와 라이브러리를 자동 관리하는 도구

• 자바 프로젝트 빌드 자동화 도구
• XML로 설정을 관리한다
• 라이브러리를 자동으로 다운로드한다
• 프로젝트 라이프사이클 관리 가능
• Apache(아파치)에서 개발

IoC 컨테이너 : 객체 생성과 의존성 관리를 수행하는 스프링의 핵심 구성 요소

• IoC(Inversion of Control) : 객체 생성과 관리의 제어권이 개발자가 아닌 프레임워크에 있는 것
• 개발자가 객체를 직접 생성하지 않고, 프레임워크가 생성한 객체를 주입받아 사용한다.
• 스프링에서는 IoC 컨테이너가 객체 생성과 의존성 주입을 담당한다.

POJO Class

• POJO (Plain Old Java Object) : 자바 모델이나, 기능, 프레임워크 등에 따르지 않고 홀로 독립적이며 단순한 기능만을 가진 객체들을 의미한다.
• 자바에서는 이러한 객체들을 Bean이라고 부른다.
• 단순히, 데이터의 저장기능만 있다.

Spring Bean 객체 생성

• Spring에서는 사용할 Bean 객체를 configuration file에 정의를 하고, 필요할 때 객체를 가져와 사용하는 방법을 이용한다.
• bean 태그 : 사용할 Bean을 정의하는 태그

인터페이스

1. 다형성(polymorphism) 부모의 참조변수로 자식객체를 생성한다.

• 코드 수정이 용이하다.

2. 상수
3. 추상메서드

MVC(Model,View,Controller)

1. Model(모델): 데이터 (주로 데이터베이스에 있는 데이터)
2. View : 사용자에게 보여주는 것(UI)

     - 템플릿 엔진을 사용해서 예쁘게 꾸며준다. (타임리프 사용)

3. Controller : 실제 일을 하는 애 (비즈니스 로직 처리)

*** dispatcher Servlet: 모든 요청을 받아서 적절한 controller에 보내는 애

MVC 장점

분업화: 요리사(모델)가 바뀌어도 서빙 방식(컨트롤러)은 그대로 유지

유지보수: "접시만 바꾸고 싶어(뷰 수정)" 할 때 요리 방법(모델)을 건드릴 필요가 없음

유연성: 같은 요리(데이터)를 접시에도 담을 수 있고, 포장 박스(다양한 뷰)에도 담을 수 있음

• @SpringBootApplication: 컴포넌트 스캔 + 자동 설정을 포함한 핵심 어노테이션
• @Component: 컨테이너에 빈(Bean) 객체로 자동 등록
• @Autowired: 타입에 맞춰 의존성을 자동으로 주입
  • 기본형(@Value)은 아니고, 참조형에만 적용됨
  • 타입을 보고 자동주입
• @Qualifier(”이름”)
  • 같은 클래스의 객체를 여러 개 만들 수 있다
• static / templates: 정적 파일(JS, CSS)과 타임리프(HTML) 템플릿 보관 폴더

@SpringBootApplication

1. @component-scan : 클래스들을 스캔해서 반으로 만들어서 컨테이너에 보관

사용자가 입력한 데이터를 받아오는 방법

1. HttpsServletRequest
2. WebRequest
3. @RequestParam : 1개씩 변수를 받는다.
4. @PathVariable : restAPI에서 사용. 폴더가 아니라 데이터로 인식하고 싶을 때 사용한다.
5. @ModelAttribute : + dto가 있어야 함(POJO 클래스 : 멤버변수+set/get만 있는 거) 클래스의 멤버변수 이름 : 요청되는 변수명하고 반드시 일치해야함.

@ResponseBody이란? return “abc”; ⇒ abc.html파일로 인식하는 것이 아니라, 단순 문자열로 인식하여 그대로 브라우저에 실행

springboot 주요 파일

• static 폴더: 정적파일 보관(html, css,js, image)
• templates: 타임리프 파일이 존재하는 폴더

@springbooApplication (1+2번을 포함하는 어노테이션)

1. <context:component-scan basePackgages=“kr.hs.study.beans”/> kr.hs.study.beans패키지아래에 있는 클래스들을 스캔해서 어노테이션을 분석한 후, 객체 생성하고, 컨테이너에 보관해라!

2. 프로젝트 실행에 필요한 기본적인 bean 들을 생성한 후, 객체에 보관해라

1. 자바 기반 응용 프로그램 개발 프레임워크
2. 2003년 6월 Rod Johnson 발표
3. 모든 Java 애플리케이션 개발 이용 ㄱㄴ
4. Java EE 기반 웹 애플리케이션 개발

⇒ Spring Framework는 기반 기술, Spring Boot는 Spring을 더 쉽고 빠르게 쓰게 해주는 도구다.

Spring Framework

• 경량 컨테이너

• POJO 방식

• IoC 지원 (제어의 역전)

  • 객체생성이나 관리 그런 부분이 Spring이 다 해줌. 개발자는 그걸 요청하는 코딩만 하면 되는 것. (예전에는 객체생성이나 관리까지 개발자가 함)

  • 제어의 역전

  • 스프링 컨테이너 객체 생성

  • 개발 효율성(up) 유지보수 용이

    <주요 특징>

    → 객체 생성, 초기화 자동 관리

    → 의존 관계를 자동으로 연결 편리 제공

    → 유연한 구조로 설정 변경 용이

    → 낮은 결합도로 유지보수 용이

    ⇒IoC는 매니저(소속사)가 있다는 느낌

• DI 지원

• AOP 지원