Life Developer
인생 개발자
Developer (136)
[typescript]class - class안에 생성자의 private 변수

class Person{

    private _age:number;

 

    constructor(private _name:string, age:number){

        this._name=_name;

        this._age=age;

    }

 

    hello():void {

        console.log(this._name);

    }

}

 

const person : Person = new Person('kim',30);

person.hello();

  Comments,     Trackbacks
[typescript]class - protected

private 은 다접근 안됨.

 

protected는 부모자식에서만 됨.

 

 

class Parent{

    private privateProp:string;

    protected protectedProp:string;

 

    constructor(){

    }

}

 

class Child extends Parent{

    constructor(){

        super();

 

        this.protectedProp='protected';

    }

}

 

console.log(new Child());

 

==========================================================

 

class Person{

    protected _name:string = 'kim';

    private _age:number=null;

}

 

class Child extends Person{

    setName(){

        this._name='fuck';

    }

}

 

const person:Child = new Child();

 

person.setName();

console.log(person);

  Comments,     Trackbacks
[typescript]class - private

class Person{

    public name:string;

    private _age:number;

 

    constructor(age:number){

        this._age=age;

    }

}

 

const person:Person = new Person(35);

person.name='mark';

//person.age=23;  불가

console.log(person);

  Comments,     Trackbacks
[typescript]interface-indexibel 은 string과 number 만 가능

string number만 가능하다.

 

interface StringArray{

    [index:number]:string,

}

 

const sa:StringArray={};

sa[100]='1';

 

interface StringDictionary{

    [index:string]:string,

}

 

const sd:StringDictionary={};

sd.numdred='a';

 

interface StringArrayDictionary{

    [index: number]:string,

    [index:string]:string,

}

 

const sad:StringArrayDictionary = {};

 

sad[100]='d';

sad['a']='a';

  Comments,     Trackbacks
[typescript]interface-함수를 프로퍼티로

interface Person{

    name:string,

    hello():string,

}

 

const person:Person = {

    name:'kim',

    hello:():string=>{return 'hello'},

}

 

interface Person1{

    name:string,

    hello?():string,

}

 

const person:Person1 = {

    name:'kim',

}

  Comments,     Trackbacks
[typescript]interface-optional property

interface Person{

    name:string,

    age?:number,

    [props:string]:any;

}

 

function hello(param:Person):void{

    console.log(`안녕? ${param.name}    입니다`);

}

 

const p1:Person={

    name:'mark',

    age:35,

}

 

const p2:Person={

    name:'anna',

    syster:['sung','chan','pang'],

}

 

const p3:Person={

    name:'gibeom',

    father:p1,

    maoter:p2,

}

 

console.log(p1,p2,p3);

  Comments,     Trackbacks
[JPA]변경감지와 병합 - 아주 중요함(진심)

준영속 엔티티가 무엇인가

 

영속성 컨텍스트가 더는 관리하지 않는 엔티티를 말한다.

 

그냥 평범하게 객체를 하나 만들었다 쳐도 기존 식별자를 set하면 (가지고 있으면)

 

준영속 상태의 엔티티,,,즉 , 객체로 볼수 있는 것이다.

 

 

그럼 준영속 엔티티를 수정하는 방법은 뭘까?

1. 변경감지 기능 사용

2. 병합 사용(merge)

 

일단 변경감지 기능을 간략히 말한다.

find로 찾아와서 그 찾아온 엔티티를 set하면 persist할필요가 있다 없다?

없다.

 

@Transactional

트랜잭션이 commit을 하는 순간 어? 영속성컨텍스트에 있는 엔티티중에 이놈이 바뀐것같네?

내가 관리하니까 수정된 내용을 DB에 insert박아야지!!!!!!!!!

 

끝.

 

이게 정석.

 

한가지 방법이 더있다 .

그것은 병합.

 

병합은 준영속 상태의 엔티티를 영속 상태로 변경할때 사용하는 기능임.

 

쉽게 말한다.

 

객체를 만든다. 이때는 걍 객체다.

객체에 정보를 set하고 em.merge(객체)를 준다.

그럼 merge는 받는 객체의 식별자, 즉 ID로 1차캐시에서 찾는다.

없네???

없으면 그냥 DB에서 똑같은 엔티티를 식별자를 이용하여 걍 조회해서 가져온다.

그럼 그 조회한 엔티티(값)를(뭐 find 한 결과(엔티티)라 생각하면됨) 영속성 컨텍스트에 담긴다.

이 엔티티에 처음에 merge가 받은 객체의 정보를 대조해 모두 set을 하여 정보를 밀어넣는다.

이 영속상태인 객체를 반환한다.

 

그리고!!!!!!!!!!! 이때 처음의 객체는 영속 상태가 아닌 객체이고!!!!

반환된 놈만 영속상태다!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

 

끝.

 

 

둘중에 왜 병합이 더 위험할까?

 

변경감지는 일단 원하는 값을 set하면 원하는 것만 바뀐다.

 

그러나 병합은 완전히 다 갈아서 대체하는것이기 때문에 객체의 값이 모두 채워져있어야 한다.

만약에 값을 안넣고 merge를 해버리면!!!!!!!!!!!!!!!!!!!!!기존 데이터는 날라가고 null이 DB에 드간다!!!!!!!!!!!

 

 

merge 안쓰면된다!!!!!!!!!!!!!!!!!!

 

Controller에서 어설프게 엔티티 생성하지 마라!!!!!!!!!!!!!!!!!!!!!!!!!!(set 쓰지말고 서비스에 메서드 만들던가

수정할 변수가 많으면 DTO클래스 그냥 하나 만들자!!!!!!!!!!!

 

트랜잭션이 있는 서비스 계층에 식별자(id)와 변경할 데이터를 명확하게 전달해라!!!!

전달해서 서비스에서 id로 find해서 select하고 그 영속엔티티에 set을 박아서 변경감지 작업해라!!!!!!

  Comments,     Trackbacks
도메인 모델 패턴, 트랜잭션 스크립트 패턴

엔티티가 비지니스 로직을 가지고 객체 지향의 특성을 적극 활용하는 것을 도메인 모델 패턴이라고 한다.

 

반대로 엔티티에는 비지니스 로직이 거의 없고 서비스 계층에서 대부분의 비지니스 로직을 처리하는

 

것을 트랜잭션 스크립트 패턴이라고 한다.

  Comments,     Trackbacks