.NET -vs ejb
https://stackoverflow.com/questions/1040840
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russian문제
.NET에서 EJB (Enterprise Java Beans)의 비슷한 기술은 무엇입니까?
해결책
.NET 3.5의 WCF는 CMP를 사용하지 않는 한 가장 유사합니다. 비누 유형에 대한 서비스 엔드 포인트를 허용하지만 바이너리 리모 팅도 가능합니다.
다른 팁
용어의 정의가 중요합니다
비교를 할 때 용어의 정의가 중요합니다. EJB는 구성 요소 모델입니다. 컨테이너 내에서 작동하는 구성 요소에 대한 지속성, 트랜잭션, 원격, 활성화 및 보안 기능 (및 기타)을 정의합니다.
.NET에서 비슷한 기술을 볼 수 있습니다. 그렇다면 구성 요소 모델의 기술적 기능 인 경우.
반면에 어떤 사람들은 "EJB"를 J2EE (또는 Java EE?)를 느슨하게 언급하기위한 용어로 사용합니다. 이 경우에는 의미가 없습니다 단지 구성 요소 모델이지만 일반적으로 구성 요소 모델을 포함한 서버 측 응용 프로그램과 관련된 관련 Java 기술 세트에. 여기에는 도구 세트가 포함될 수도 있습니다. 물론 구성 요소 모델과 접선으로 만 관련이 있습니다. 만약에 저것 비교는 "j2ee vs. .net"으로 더 적절하게 묘사됩니다.
여전히 다른 사람들은 웹 서비스 기능, REST/XML 커뮤니케이션 또는 Java EE 또는 EJB 외부에있는 다른 것들과 같은 것들을 포함시키기 위해 EJB에 대해 더 희미한 정의를 사용하고있을 수 있습니다. 즉, "EJB 비교와 .NET"이라고 말할 때 실제로 "서버 측 Java 플랫폼을 서버 측 .NET과 비교하는 것"을 의미합니다. 후자는 구성 요소 모델을 비교하는 것보다 훨씬 더 실용적인 비교로 나를 공격합니다.
비교를 할 때 비교중인 것에 대해 명확하게하는 것이 중요합니다.
EJB- 구성 요소 모델
EJB에서는 물체를 정의하고 세션 Bean 또는 엔티티 콩으로 표시합니다. 메시지 구동 콩의 늦은 추가도 있습니다. EJB의 구성 요소의 세 가지 맛. 세션 Bean은 활성화 - 서버/컨테이너에서 자원 경합이 높은시기에 시작하고 "통행"하는 방법을 활성화합니다. SB는 또한 보안 및 원격 서비스를 제공합니다.
기본 아이디어는 객체를 정의한 다음 배치 디스크립터 또는 코드 내 속성을 통해 객체를 첨부하는 것입니다. 주석 자바에서.
EJB 세션 Bean과 가장 가까운 것은 .NET 객체입니다. 모든 .NET 응용 프로그램에서는 EJB SB와 마찬가지로 트랜잭션 속성이있는 객체를 표시 할 수 있습니다. .NET 리모 팅 및 더 많은 속성으로 원한다면 원격으로 만들 수 있습니다. COM+외에는 .NET에는 패시베이션 기술이 없습니다. .NET은 풀링을 일반적으로 메모리 내 객체와 관련된 흥미로운 일로 무시하며, 그 결과 EJB와 같이 .NET에서 활성화/패시베이션을 수행하는 방법이 없습니다.
사이드 바 #1 : 그것은 사실이 아닙니다. .NET에서 워크 플로 기능은 통행 및 재 활성화 될 수 있고 재 활성화 될 수있는 장기적인 활동을 할 수있는 시설을 제공합니다. 그러나 워크 플로는 .NET을 사용하는 대부분의 서버 측 응용 프로그램 아키텍처의 중심 인 "서버 측 개체"또는 "서비스"와는 다른 은유입니다.
사이드 바 #2 : 서버 측 플랫폼의 디자이너는 모든 사람들이 더 효율적으로 객체 풀링을 사용하고 싶다고 생각했던 것입니다. 이제 JVM 및 .NET CLR은 객체를 만드는 데 충분히 빠르며 메모리는 충분히 충분히 충분히 많으며 일반적으로 객체 풀링은 실용적이지 않습니다. 데이터베이스 연결과 같은 비싼 개체에 대해 여전히 좋은 배당금을 지불하지만 더 이상 일반적인 경우에는 더 이상 흥미롭지 않습니다.
EJB와 마찬가지로 .NET에서 보안 속성을 객체에 첨부하여 발신자의 신원 또는 기타 "증거"에 따라 실행되거나 실행되지 않도록 할 수 있습니다.
엔티티 콩은 다른 동물입니다. 지속성과 원격을 결합 할 수 있지만 대부분의 실제 가이드 북에서는 엔티티 Bean이 원격 인터페이스를 노출시키지 않는 것이 좋습니다. 대신 추천은 세션 Bean이 엔티티 Bean을 호출하도록 요구합니다. EB를 지속적인 대상으로 간주합시다.
.NET에는 여기에 많은 대안이 있습니다. LINQ-to-SQL은 ORM 및 Persistence Services와 함께 하나의 옵션을 제공합니다. Ado.net 엔티티 프레임 워크는 아마도 더 비슷한 기술 일 것입니다. 물론 .NET의 다른 모든 서비스 - 트랜잭션 보안 및 리모 팅 등 - ADO.NET 엔티티 프레임 워크 또는 LINQ를 사용하는 개체에도 적용 할 수 있습니다.
반면에, EJB 우산의 강조 위치에 따라 비교가 더 좋을 수 있습니다. 원격으로 EJB를 주로 사용하고 휴식, 비누 및 기타 경량 프로토콜의 출현으로 더 이상 내가 알 수있는 한 아무도 이것을 할 수 없다면 .NET에서 더 나은 비교할 수있는 것은 WCF입니다.
마지막으로, EJB MDB와 비슷한 것은 .NET 대기열 구성 요소입니다.
EJB 리모 팅
원격 인터페이스와 같은 이러한 모든 유형의 EJB에는 몇 가지 일반적인 측면이 있습니다. 실제로 대부분의 건축가는 EJB를 배포하지 않는 것이 좋습니다. 다시 말해, 그들은 사람들이 일반적으로 논의되는 원격 측면을 사용하지 못하게합니다. 대신 서블릿은 원격 시스템에서 eJB를 호출하지 않고 로컬 인 EJB를 호출해야합니다. 이것은 파울러의 첫 번째 법칙: 객체를 배포하지 마십시오.
반면에, 때때로 당신은해야합니다.
WCF는 .NET 내의 통신 프레임 워크이며 EJB 리모 팅과 가장 비슷한 .NET의 측면입니다. 그러나 그들은 동등하지 않습니다. WCF는 원격 통신, 지원 동기 및 비동기, 다중 프로토콜 및 확장 가능한 전송 및 채널 모델을위한 매우 일반적인 목적 프레임 워크이며 EJB 리모 팅은 상당히 제한적입니다.
EJB에서 시작하여 올바른 접근 방식입니까?
EJB는 웹 서비스, 휴식, 관리 또는 가벼운 프레임 워크, HTML 또는 개발자 도구에 대해 (내가 아는 한) 아무 말도하지 않습니다. "EJB vs.와 비교 시작 공백"토론을 조금만 제한합니다. 그것은 최적이 아닌 방식으로 토론을 틀었습니다.
예를 들어 HTML 페이지 은유를 처리 할 EJB에는 아무것도 없습니다. 당신은 그것을 서블릿 또는 사촌 중 하나 (포틀릿 등)로 얻습니다. 그 중 일부는 J2EE에 적합합니다. 그러나 엄격하게 말하면, HTML 출력은 EJB에서 다루지 않습니다.
이제 EJB의보다 광범위한 정의 중 하나를 의도 할 것입니다. 이를 위해 J2EE는 이제 사양에 웹 서비스를 추가했습니다. 그러나 그럼에도 불구하고 비누 웹 서비스 및 휴식을위한 다양한 추가 자바 기반 프레임 워크와 함께 사양을 고려하는 것이 얼마나 관련이 있는지 잘 모르겠습니다.
마찬가지로, 포틀릿, 서블릿 및 ajax와 같은 UI 기능을 고려하여 .NET 등가물과 비교하려면 EJB와 J2EE를 넘어 서버 측 Java로 옮겼습니다.
그것은 나의 이전 시점으로 돌아갑니다 - 당신이 검사하거나 비교하는 데 관심이있는 것에 대해 자신의 마음에 명확하고 정확합니다.
EJB 및 J2EE 사양은 야심적이었습니다. 서버 측 응용 프로그램의 프레임 워크를 정의하려고 시도했습니다. 그러나 개발자가하고있는 일, 사양의 말, 공급 업체가 제공 한 내용 사이에는 항상 시간이 지연되었습니다. 아마도 새로운 버전의 J2EE 사양의 최종화와 IBM의 호환 서버 릴리스 사이에 1 년의 지연이 있었을 것입니다.
이 때문에 결국 그것은 일종의 인공적이고, 이후에 나타났습니다. 사양은 사람들이 이미하고있는 일을 묘사하고있었습니다. 봄과 같은 것들이 나오고 J2EE는 그들에 대해 아무 말도하지 않았습니다. 가장 오랫동안 J2EE는 REST 또는 웹 서비스 또는 AJAX에 대해 아무 말도하지 않았습니다. (지금도 Ajax에 대해 아무 말도합니까? 모르겠어요.)
사양 이론과 개발자의 실제 실습 현실 사이의 거리에 비추어 볼 때, 더 나은 접근 방식은 응용 프로그램 요구 사항을 식별 한 다음 EJB 및 기타 관련 기술의 적절성을 구축하려는 앱과 비교하는 것입니다.
다시 말해서 - 요구 사항 중 하나가 앱이 브라우저를 통해 전달되고 Ajax의 응답 성이 있다고 가정합니다. 이 경우 jQuery를 고려해야하며 J2EE 또는 EJB에서 다루는 곳은 없습니다. Ajax 프레임 워크는 다양한 제품 (Java 및 .NET)에서 제공됩니다. 예를 들어 Visual Studio는 aspnet ajax 물건에 jQuery를 사용합니다. 그러나 사양을 고수하면이 물건이 그리워요.
결론
결론은 EJBS로 구축하는 모든 앱은 .NET로 구축 할 수 있으며 그 반대도 마찬가지입니다.
"EJB vs .NET"과 같은 비교는 학업 토론으로 관심이있을 수 있다고 생각하지만 어디에서 사용할 기술에 대한 실질적인 통찰력을 원한다면 조금 다르게 생각해야합니다.
개발 속도, 배포 비용, 배포 메커니즘, 도구 지원, 배포 플랫폼 지원, 언어 지원, UI 모양, UI 옵션 등과 같은 요구 사항을 식별하고 우선 순위를 정해야합니다.
Spring.net을 쉽게 논쟁 할 수 있습니다 ...
봄은 Javaee/EJB 외에도 Java 측에서 표준이되고 있거나 완전히 교체하고 있습니다. 봄의 많은 개념은 Javaee/EJB와 매우 유사하지만 단순히 더 좋습니다. Spring.net은 분명히 .NET 구현입니다.
이 외에도 몇 년 동안 .NET을 적극적으로 사용하지 않았기 때문에 다른 것을 제안 할 수 없었습니다.
많은 EJB 기능은 이미 .NET (IE 데이터베이스 트랜잭션)에 이미 기본이지만 엔터프라이즈 서비스 네임 스페이스도 많은 기능을 제공합니다.
