Naked Objects. 좋거나 나쁨

Question

나는 최근에 벗은 물건에 노출되었습니다. 꽤 괜찮은 프레임 워크처럼 보입니다. 그러나 나는 봄 같은 말처럼 널리 사용되지 않습니다. 그렇다면이 프레임 워크가 주류 애플리케이션 크레딧을 얻지 못하는 이유는 무엇입니까? 그 결점은 무엇입니까?

Answer 1

가 NOF 3.0.3를 사용하지 않는 응용 프로그램 개발자에 정면으로 성공적인 응용 프로그램을 개발하는 부담이 있기 때문에

플러스, 시장에 많은이없는 ...

좋은 : 어떤 db4o는 것은 지속성의 경우와 같이

• 는 자동적으로 도메인 객체에 대한 드래그 & 드롭 인터페이스를 생성한다.
• 이것은 MVC 패턴 작성자에 따르면 MVC가 항상 의도했던 것입니다.
• 프레임 워크는 도메인 객체 (POJO)가 모든 최소 배선 인 AbstractDomainObject에서 서브 클래 싱되도록 요청합니다.
• 프레임 워크는 일반적인 구성보다 유리합니다. 많은 주석이 사용되었습니다.
• 지속성을 위해 db4o와 함께 프로토 타이핑에 유용합니다.
• 최대 절전 모드의 기본 기능.
• 필자의 경우 Hello World 앱 다운로드에서 30 분이 필요했습니다. (IntelliJ IDEA IDE)
• JNLP, 독립 실행 형, 웹 (NOX 내장 Jetty 또는 Scimpi 맛) 및 Eclipse RCP로 배포.
• 포럼에서 도움을 요청할 때 NOF 팀이 항상 귀하를 위해 있습니다.
• Naked Object Pattern은 멋진 아이디어입니다. 자신에게 호의를 베풀고 시간을내어 그것을 깬다.
• 는 드래그 앤 드롭 GUI 주위에가는 불타는 유용성을 많이 Theres는하지만 미래의 최종 사용자가 단순히 통화 거부 UI하지 일이 당신이 곤경에 수 있다면 어쨌든.

나쁜 : 내가 생각할 수있는

• 없음.

the 일종의 추한 : 허용

• 없음 스윙 구성 요소, 그래서 JGoodies 모든 당신의 마음에 드는 스윙 컴포넌트 세트에 작별 인사. UI 구성 요소는 맞춤형입니다. 90 년대 초의 VB 컨트롤처럼 보입니다. 그러나 작품에는 SWT 포트가 있습니다.
• 긴 문자열의 여러 줄 필드에는 몇 가지 문제가 있습니다. (NOF 3.0.3)
• 이미지 용 DnD UI는 다소 버그가 있습니다.
• getters n setters에 대한 유효성 검사 코드는 도메인 개체가 UI에서 수정 된 경우에만 발생합니다. (이것은 아마도 n00bness 때문에 잘못되었습니다. NOF 커미터가 나를 고칠 수 있기를 바랍니다.)

• 오브젝트가 비 -ui 스레드에서 수정 된 경우, b. 작업자, 그러한 개체는
  화면에보기를 업데이트하지 않습니다. 이렇게하면 DnD 자동 생성 UI에서 실시간으로 메일 대기열을 나타내는 것과 같은 사용 사례가 무효화됩니다. (다시)

• Veikko

Answer 2

here in Ireland 성공적으로 사용되었습니다.

나는이되어 더 인기가 었소 이유 생각 :

• 당신은 당신이
• 그것은 GUI를 만들어 사용하는 툴킷에 대한 자신감이 많이 필요를 대신 생각할의 위험 인자 (모두 기술적 초점 대부분으로 존재하는 곳이다 사용성 테스트) 내가 아는 한) (웹에
• 그 적용되지 ...

Answer 3

에서 가레스 몇 가지 우수한 점을 만든다.

룩앤필을 제어하기 어렵다는 점과 창 모델에 익숙해 진 사람들에게는 직관력이 떨어지는 것과 같은 다른 문제가 있습니다. 또한 모든 응용 프로그램 도메인이 직접 표현을 표현할 수있는 것은 아니라는 점에서 모델링 문제가 있습니다.

스몰 토크 및 알몸 개체 커뮤니티에서지지받는 '시민 프로그래머'의 일반적인 모델도 의심스러운 아이디어로 간주됩니다. 대부분의 사용자는 기능 자체를 변경하는 데 큰 어려움을 느끼지 않으므로 객체를 생각하는 것이 그렇게 유용하지는 않습니다.

Answer 4

저는 작년에 그걸 가지고 놀았고, 함께 일하기가 매우 쉽다고 결론을 냈습니다.

Naked Objects의 강점은 무료로 데이터 모델에 따라 GUI를 구성한다는 것입니다. 단점은 일반 사용자가 그의 프로세스를 레코드 컬렉션으로 생각하지 않는다는 것입니다.

결론적으로 Naked Objects는 인벤토리 응용 프로그램이나 청구 처리 응용 프로그램과 같이 레코드를 개념적으로 처리하는 내부 응용 프로그램에 정말 좋습니다.

프레임 워크를 사용자의 취향에 맞게 수정해야하는 경우 원하는 응용 프로그램을 지원하기 위해 작성된 프레임 워크를 사용하는 것보다 훨씬 많은 작업이 필요할 수 있습니다.

그런데 웹 렌더링 옵션이 있습니다. 자세한 내용은 Naked Objects Demo의 데모를 참조하십시오.

Answer 5

아마도 주목을받지 못했던 이유는 J2EE 세계가 너무 많은 레이어를 응용 프로그램에 쌓아두기 위해 사용 되었기 때문입니다. 즉, 알몸의 객체가 순진한 것처럼 보입니다.

Google 서비스는 어디에 있습니까? 누드 된 객체로 인해 데이터베이스에 즉시 액세스 할 수 있다는 의미입니까? RMI 호출로 애플리케이션을 노출해야한다면 어떻게해야할까요? 내 경험에서 프레임 워크 개발자 :

Answer 6

나는 단지이를 보았다. 몇 가지 사소한 수정, 그렇지 않으면 대부분의 의견은 매우 공정합니다.

1) '프레임 워크는 도메인 객체 (POJO)가 모든 최소 배선 인 AbstractDomainObject에서 서브 클래 싱되도록 요청합니다.'

Naked Objects는 일반적으로 도메인 개체를 AbstractDomainObject에서 서브 클래 싱하지 않아도되지만 일반적으로 가장 편리한 방법입니다.

상속하지 않으려면 IDomainObjectContainer 유형의 속성을 제공하기 만하면 프레임 워크가 생성되거나 검색 될 때 프레임 워크가 개체에 개체를 주입합니다. 컨테이너에는 프레임 워크가 사용자 도메인 객체와 동기화 상태를 유지할 수 있도록 사용해야하는 프레임 워크와 최소한의 3 개의 접촉점 인 Resolve(), ObjectChanged() 및 NewTransientInstance()에 대한 메소드가 있습니다.

2) '지속성을 위해 db4o와 함께 프로토 타이핑하기에 좋습니다.' 우리는 db4o로 작업한다는 아이디어에 열중하고 있지만, Naked Objects와 db4o를 함께 사용하는 사람은 누구인지 알지 못합니다. 누구든지이 일을했다면, 그것에 대해 더 듣고 싶습니다.

3) '작은 토큰과 누드 객체 커뮤니티에서지지하는 citzen 프로그래머의 일반적인 모델 ...'. 우리는 결코 그 아이디어에 동의하지 않았으며 나는 그것에 동의하지 않습니다. Naked Objects는 사용자가 프로그램을하도록 장려하는 것이 아닙니다. 나는 전문 개발자의 역할을 확실하게 믿고 있습니다. Naked Objects는 더 나은 소프트웨어와보다 생산적으로 작성하는 데 도움이됩니다. 기술의

리처드

Answer 7

• 광범위한 사용은 기술적 품질에 더 강한 상관 관계가 없습니다.
• nakedobject 시스템은 유형 객체와 함께 사용하기가 어렵습니다. 다른 제품을 판매 할 때 다른 제품에 대해 다른 데이터가 필요하다면 제품 유형에 대한 데이터를 제한하기가 어렵습니다.
• 라이센스를 전환 할 때 잃어버린 기세는 없습니다. (GPL + 상용으로, 최근 아파치로 옮겨서가 아님)

jmatter를 살펴 보셨습니까?

[편집] 또 다른 한 가지 : 제공 할 수있는 경우 프로그래머가 아닌 사람에게 분명하게 알립니다. Spring은 기술적 영역에서 매우 중요합니다. NO는 개발자가 사용자와 대화해야 함을 의미합니다. 대기업은 그렇게하지 않습니다.

Answer 8

NakedObject는 확실히 관련성이 있으며 개발자 커뮤니티가 실제로 그 (것)들을 지불하고있는 무슨을에 초점을 맞춘다보다는 더 많은 것을 짐작한다 : 사업. 대신 우리는 대부분 인프라, 프로토콜 및 모든 기술적 인 허튼 소리로 시간을 보냅니다. 이러한 미스 생성 응용 프로그램을 보았고 심지어 주류를 따라가는 일부 작업을 수행해도 시스템을 계층화하는 것이 항상 좋은 일이라는 것을 가르쳐주었습니다. 최악의 경우는 일부 개발자에게 그들이 어떤 회사의 비즈니스에 대해 묻는다면, 비즈니스에 대해 더 깊이 이해하지 않고도 수년간 회사에서 근무한 일부 직원을 찾을 수 있다는 것입니다. 그러나 NakedObject는 UI 개발을 좋아하고 비즈니스 요구 사항에 맞게 업무를 처리하기 때문에 단순히 개발자가 (대개 DomainDrivenDevelopment에서 영감을받은 개발자조차도) 대다수의 개발자를 유치 할 것이라고 생각하지 않습니다. 그들이 원하는 바가 아닙니다. 우리는 모두 VB의 바보입니다.

Answer 9

NakedObjects (NO)는 빠른 프로토 타이핑에 적합합니다. GUI, DB 및 솔루션의 다른 부분에 신경 쓰지 않고도 도메인 모델에 집중할 수 있습니다. 생산을 위해서는 NakedObjects 프레임 워크 자체에서 개선 (버그 수정, 데이터 매핑, GUI 등)이 많이 필요합니다.

솔루션에 대해 "개념 증명"을해야하는 경우 NO를 사용할 수 있습니다.그러나 생산을 위해서는 NO 프레임 워크 개발에 자원을 투자 할 준비가되어 있어야합니다.

최근 BT는 NO 4.0 용 GWT를 기반으로 DnD 뷰어를 만드는 중입니다.

Answer 10

저는 1 년 넘게 누드 객체 접근법을 연구 해 왔으며 시스템 아키텍처에 제공되는 가능성을 보여주기조차하지 않았습니다. 그러나이를 제대로 활용하려면 패러다임 전환을 만들고 전체 OO 솔루션을 찾아 기능적인 덕트 테이프를 사용하지 않아야합니다. 패러다임은 고급 개발을 가능하게하는 디자인을 만들 때만 작동하는 것처럼 보입니다.

Django가 Django Models 내에서 Naked 개체를 구현 한 방법을 절대적으로 좋아합니다. 제가 프레임 워크에 대해 좋아하는 대부분의 것들은 제가 믿기로 한 것입니다. 모델의 직접적인 결과와 맨 위에있는 몇 가지 놀라움이 있습니다. 나는이 아키텍처에 대해 공유하고 싶습니다.

모델 필드는 테이블 컬럼에 맵핑하는 것은 행동 적으로 완전한 객체입니다 - 애플리케이션과 데이터베이스 도메인에서 어떻게 표현되는지, 객체와 객체간에 변환되는 방법 및 보유한 정보가 입력에 대해 시각적으로 사용자에게 확인되고 표시되는 방법을 알고 있습니다. . 이 모든 것은 모델에서 한 줄의 코드로 활용됩니다. 와우!

관리자는 모델에 첨부되어 있으며 재사용 가능한 쿼리 (마지막 5 개의 블로그 게시물, 가장 많이 발생하는 태그 등 제공), 대량 삭제 \ 업데이트 작업 및 수행 된 비즈니스 논리와 같은 CRUD 및 모든 일반 작업을 컬렉션에 제공합니다 인스턴스에. 와우!

이제 사용자를 나타내는 모델이 있다고 가정합니다. 때로는 사용자 모델이 보유하고있는 모든 정보를 부분적으로보고 싶을 때가 있습니다 (사용자의 비밀번호를 재설정 할 때 사용자의 전자 메일과 비밀 질문 만 필요할 수 있습니다). 모델 데이터의 일부분에 대해서만 입력을 정확하게 표시하고 관리하는 Forms API를 제공했습니다. 사용자 입력을 처리하는 방법을 사용자 정의 할 수 있습니다. 와우!

결과적으로 모델은 특정 도메인을 설명하는 데 사용하는 정보를 설명하는 데에만 사용됩니다. 관리자는 모델에 대한 모든 작업을 수행합니다. 양식은보기를 작성하고 사용자 입력을 처리하는 데 사용됩니다. 컨트롤러 (뷰)는 HTTP 동사를 처리하기위한 용도로만 사용되며 모델로 작업하는 경우 관리자와 양식을 통해서만 사용할 수 있습니다. 프레젠테이션 (자동 생성 할 수없는 부분)에 대한보기 (템플릿)가 있습니다. 이것은 imho는 매우 깨끗한 아키텍처입니다. 서로 다른 관리자가 서로 다른 모델에서 사용 및 재사용 될 수 있으며 모델마다 다른 양식을 작성할 수 있으며, 다른보기는 다른 관리자를 사용할 수 있습니다. 이러한 분리 등급을 통해 응용 프로그램을 신속하게 설계 할 수 있습니다.

지능형 객체의 생태계를 만들고 상호 연결된 방식으로 전체 응용 프로그램을 만들 수 있습니다. 느슨하게 결합되어 있다는 점을 전제로하고 (패러다임에 따라 몇 가지 라인을 사용하여 쉽게 수정할 수 있고 확장 할 수 있음), 실제로 패러다임에 따라 구성 요소를 한 번 작성한 다음 다른 프로젝트에서 재사용하십시오. 그것은 MVC가 항상 있었어야하는 것입니다. 그러나 저는 전에 몇 프로젝트에서 똑같은 일을 했음에도 종종 처음부터 무언가를 써야했습니다.