Stateless vs Stateful-구체적인 정보를 사용할 수 있습니다.

프로그래밍에서 상태 비 저장 및 상태 저장 디자인에 대한 구체적인 정보가있는 기사에 관심이 있습니다. 더 많이 알고 싶어서 관심이 있지만, 좋은 기사를 찾을 수 없습니다. 나는 주제에 대해 모호하게 논의하는 웹에서 수십 개의 기사를 읽었거나 웹 서버 및 세션에 대해 이야기하고 있습니다.이 기사는 상태 저장과 상태 비 저장에 대해 이야기하지만 코딩에서 상태 비 저장과 상태 저장 속성 설계에 관심이 있습니다. . 예 : BL 클래스는 설계 상 상태 비 저장이고 엔티티 클래스 (또는 적어도 Person (id, name, ..))는 상태 저장 등 내가 부르는 것입니다.

내가 그것을 이해할 수 있다면 더 나은 코드를 작성할 수 있다고 믿기 때문에 아는 것이 중요하다고 생각합니다 (예 : 세분성을 염두에두고 있습니다).

어쨌든, 정말 짧게, 상태 저장과 상태 비 저장에 대해 내가 아는 것은 다음과 같습니다.

상태 저장 (WinForms 등) : 추가 사용을 위해 데이터를 저장하지만 CPU 또는 메모리 제한에 의해 제한되기 때문에 응용 프로그램의 확장 성을 제한합니다.

상태 비 저장 (ASP.NET과 유사-ASP는 ViewStates로 상태 저장을 시도하지만) : 작업이 완료되면 데이터가 전송되고 인스턴스가 스레드 풀 (Amorphous)로 다시 전달됩니다.

보시다시피, 그것은 매우 모호하고 제한된 정보입니다 (그리고 서버 상호 작용에 상당히 집중되어 있습니다). 그래서 좀 더 맛있는 정보를 제공해 주시면 정말 감사하겠습니다 :)

Stateless 프로그래밍의 장점을 설명하는 StackOverflow 의 질문 에서 시작하는 것이 좋습니다 . 이것은 함수형 프로그래밍의 맥락에 더 가깝지만 읽을 내용은 다른 프로그래밍 패러다임에도 적용됩니다.

Stateless 프로그래밍은 동일한 인수로 호출 될 때 항상 동일한 결과를 반환하는 함수의 수학적 개념과 관련이 있습니다. 이것은 함수형 프로그래밍 패러다임의 핵심 개념이며 해당 영역에서 많은 관련 기사를 찾을 수있을 것으로 기대합니다.

더 많은 이해를 얻기 위해 조사 할 수있는 또 다른 영역은 RESTful 웹 서비스입니다. 이는 상태를 유지하려는 다른 웹 기술과 달리 "상태 비 저장"상태입니다. (사실 ASP.NET이 상태 비 저장이라고 말하는 것은 올바르지 않습니다. ASP.NET은 ViewState를 사용하여 상태를 유지하려고 노력하며 확실히 상태 저장으로 특성화됩니다. 반면에 ASP.NET MVC는 상태 비 저장 기술입니다). RESTful 웹 서비스 (예 : 이 블로그 지점) 의 "상태 비 저장"에 대해 논의하는 곳이 많지만 SO 질문 에서 다시 시작할 수 있습니다.

Stateless 는 과거에 대한 기억이 없음을 의미합니다. 모든 트랜잭션은 마치 처음으로 수행 된 것처럼 수행됩니다.

Stateful 은 과거의 기억이 있음을 의미합니다. 이전 거래는 기억되며 현재 거래에 영향을 미칠 수 있습니다.

무국적 :

// The state is derived by what is passed into the function

function int addOne(int number)
{
    return number + 1;
}

상태 저장 :

// The state is maintained by the function

private int _number = 0; //initially zero

function int addOne()
{
   _number++;
   return _number;
}

참조 : /software/101337/whats-the-difference-between-stateful-and-stateless

상태 응용 프로그램은 하나가 발생하거나 실행 시작한 이후의 변경 사항에 대한 정보를 저장가. 어떤 "모드"에 있는지, 처리 된 레코드 수 등에 대한 모든 공개 정보는 상태 저장을 만듭니다.

상태 비 저장 앱은 해당 정보를 노출하지 않습니다. 매번 동일한 요청, 함수 또는 메서드 호출에 동일한 응답을 제공합니다. HTTP는 원시 형식의 상태 비 저장입니다. 특정 URL에 대해 GET을 수행하면 (이론적으로) 매번 동일한 응답을받습니다. 물론 ASP.NET 웹 앱과 같이 상태 저장을 추가하기 시작할 때는 예외입니다. 그러나 HTML 파일과 이미지 만있는 정적 웹 사이트를 생각하면 제가 의미하는 바를 알 수 있습니다.

형용사 Stateful 또는 Stateless는 대화의 상태만을 나타내며 동일한 입력에 대해 동일한 출력을 제공하는 기능의 개념과 관련이 없습니다. 그렇다면 동적 웹 애플리케이션 (데이터베이스가있는)은 상태 저장 서비스가되며 이는 명백히 거짓입니다. 이를 염두에두고 기본 기술 (예 : coockie 또는 http 세션)에서 대화 상태를 유지하는 작업을 맡기면 상태 저장 서비스를 구현하고 있지만 필요한 모든 정보 (컨텍스트)가 매개 변수로 전달되면 m 상태 비 저장 서비스 구현. 전달 된 매개 변수가 대화 상태 (예 : 티켓 또는 세션 ID)의 "식별자"인 경우에도 우리는 여전히 상태 비 저장 서비스에서 작동하고 있습니다.

한 계정에서 다른 계정으로 온라인으로 이체 된 돈은 수신 계정에 송금인에 대한 정보가 있기 때문에 상태 저장입니다. 한 사람에게서 다른 사람에게 현금을 넘겨 주면이 거래는 무조건적입니다. 현금을받은 후에는주는 사람의 신원이 현금과 함께 없기 때문입니다.

다른 사람의 기여를 추가하기 위해 .... 또 다른 방법은 웹 서버와 동시성의 관점에서 보는 것입니다 ...

HTTP는 본질적으로 상태 비 저장입니다. 웹 서버의 경우 상태 저장 이란 사용자의 마지막 연결에 대한 '상태'를 기억하고 / 또는 요청자와의 열린 연결을 유지해야 함을 의미합니다. 수천 개의 동시 연결이있는 애플리케이션에서는 비용이 많이 들고 '스트레스'가 발생합니다.

인 상태 비 저장 이 경우은 열 및 / 또는 마지막 요청에서 아무것도 기억 오버 헤드 유지 연결 ... 요청 및 응답의 단일 인스턴스에서 연결을 지원하지 자원의 명백한 효율적으로 사용 ... 즉이 ...

세션 객체를 사용하여 HTTP stateless 동작을 재정 의하여 Webapps statefull을 만듭니다. 세션 객체를 사용하면 상태가 전달되지만 여전히 HTTP 만 사용합니다.

나는 stateful v / s stateless 클래스 디자인에 대해 똑같은 의구심을 가지고 몇 가지 조사를했습니다. 방금 완료되었으며 내 결과가 내 블로그 에 게시되었습니다 .

• 엔티티 클래스는 상태 저장이어야합니다.
• 도우미 / 작업자 클래스는 상태 저장이 아니어야합니다.