[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]

: name

: password

: homepage secret mode

1. C-Thinker 2010/01/20 16:58 Modify/Delete Reply

   안녕하세요. 변론을 하신다기에 들어와 봤습니다. ^^
   우선 지적하신 부분들에 대해서 변명을 하겠습니다.
   
   Table Module 에 대해서는 그 패턴을 사용했다기 보다는 개념적인 기반이 되어 있다고 표현을 한 것입니다.
   ORM 과 Persistence Ignorance 에서는 솔직히 무슨 말씀을 하려 하시는지 잘 이해가 가지 않는군요.
   객체와 테이블이 1:1 관계라고 표현한 부분에서는 테이블이라고 썼는데 사실 그 전에 언급한 모델을 그렇게 써 버렸군요. 도메인 모델을 지원을 하려면 기존의 도메인 모델과 EF가 만들어낸 모델과의 자유로운 매핑이 가능해야 한다고 생각합니다.
   POCO 와 ObjectContext 에 대해서 말씀드리자면, 개발자가 어떤 이유에서든 자유의지로써 의존성을 만들게 될 수는 있지만 프레임워크에서 강제해서 발생되는 의존성하고는 많은 차이가 있다는 생각입니다. 개발자가 만든 의존성도 나중에 문제가 되는데 프레임웍에서 의존성을 갖도록 강제를 당한다면 추후 확장성에 많은 문제가 발생할 소지가 많습니다.
   
   어쨋든 다른 관점에서 볼 수 있는 기회를 주신것에 감사드립니다.

   • 스맥 반더빌트 2010/01/20 18:04 Modify/Delete

     네 Thinker님 또 뵙게 되었습니다.
     
     Table Module Pattern에 대해서는 L2S이 가깝다고 할 수 있습니다. EF는 L2S에 논리 모델이 더해진 것으로 생각할 수 있네요, 또한 EF Table Module Pattern 을 기반으로 한다 해도 그것이 문제인가? 라는 의견입니다.
     
     "PI는 PI 의 정의 및 룰이 완벽하지 않은 데다가, 전적으로 ORM의 책임은 아니다 라는 의미이며, 도메인 모델은 Repository 패턴 등을 이용함으로써 PI를 일정부분 충족 시킬수 있다" 라는 의미입니다.
     
     
     POCO와 ObjectContext의 문제에 대해서는 Thinker님의 문제 의식에는 동의 하나, POCO를 영속화하기 위한 또다른 방법의 필요가 요구됩니다. 이것을 ObjectContext가 담당하도록 하는 일관적인 패턴에 대해서 동의 한다는 말입니다.
     
     DTO 예를 든 것은 불가피한 의존성의 발생 현실을 말하고자 함이며 , 의존성이 없이도 작동하는 해결책이 있다면 저도 매우 기뻐하고 싶습니다.

2. 권효중 2010/01/21 16:41 Modify/Delete Reply

   EF 베타버전을 아직 저도 써보지는 않았지만 지난 PDC2009 의 EF 세션에서 보여준 데모에는 객체에서 데이타베이스를 생성하던데요..

   • 스맥 반더빌트 2010/01/21 21:01 Modify/Delete

     네 효종님
     
     EF는 .NET Framework 3.5 SP1에 정식 포함 되어 V1 이었으나, 다음 버전은 .NET Framework 4.0에 포함되어 EF4 로 불리웁니다.
     
     EF V1에서는 Entity를 DB에서 부터 생성 + 모델 디자이너에서 생성 할 수 있으나, Custom Entity에 대해서 DB에 반영 할 수는 없었습니다.
     
     EF 4.0(V2) 에서는 EDM 디자이너에서 생성한 Custom Entity를 DB에 테이블로 생성 할 수 있도록 기능이 업그레이드 되었답니다.
     
     EF 4.0의 새로운 기능은 EDM으로 부터 DB로의 테이블 생성, POCO 지원 등이 있습니다.

[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]

: name

: password

: homepage secret mode

[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]

: name

: password

: homepage secret mode

1. 도둑갈매기 2010/01/06 09:23 Modify/Delete Reply

   트랙백 보고 왔는데, 많은 공감이 가는 글 입니다. 정리도 깔끔하게 잘 하셨네요.
   저는 현재 작은 프로젝트 PM 을 하고 있는데 ,개발자 태생이 아닌 경영학 태생이다 보니
   개발자를 이해 못하는 부분도 많은 것 같습니다.
   프로젝트를 위하여 그리고 나 자신을 위하여 좀 더 상대방이 하는 일에 잘 알아야 할 것 같네요

   • 반더빌트 2010/01/06 10:05 Modify/Delete

     안녕하세요 도둑갈매기님.
     개발자가 기획자에게 가장 바라는 것은 "기획서가 비지니스 목표를 논리적으로 만족 시키느냐" 일 겁니다. 완벽하게 논리적인 것을 소프트웨어로 구현 하는 것도 100% 확신 할 수 없는데 , 기획의 비논리는 소프트웨어도 비논리적으로 만듭니다. 소프트웨어가 비 논리적 이라는 것은 '동작하지 않는다'의 의미입니다.
     
     최종 결과물을 책임지고 있는 개발자는 제품을 두고 변명이 불가능 합니다. 요구사항을 안 들을 수도 없습니다. 결국에는 개발자 자신이 제품을 수정해야 하니까요.
     
     자신의 분야에서 최대한의 노력한 결과물을 전달 하는 것이 서로를 이해 하는 첫번째 라고 생각합니다.

2. 아름드리 2010/01/06 09:49 Modify/Delete Reply

   Java나 .NET 혹은 다른 플랫폼을 사용해서 개발을 진행하게 되더라도 위와 비슷하게 필요하다고 생각됩니다.
   이런 것을 보면 우리나라의 4~6개월 IT 교육과정은 정말 터무니 없다고 생각됩니다.

   • 반더빌트 2010/01/06 10:11 Modify/Delete

     아름드리님 생각에 전적으로 동의 합니다. 컴퓨터공학을 전공하고, 개발업무에 수년을 몸담아도 내가 개발자로서의 자격을 가지고 있는 것인가를 고민하게 만드는 영역이 개 영역이라고 느껴집니다. 끝이 없는 자기계발이 필요함은 몇년을 개발로 버틸수 있을 것인가를 자문하게 만듭니다.
     개발을 4~6개월 교육과정으로 가능하다고 생각 하는 자체가, 교체가능한 단순노동으로 보는 현실을 만들어낸 큰 요인으로 생각합니다.

3. DIFF 2010/01/07 14:43 Modify/Delete Reply

   저도 비슷한 일들을 해 오고 있는 입장이지만, 이렇게 길게 차곡차곡 쉽게 설명하기란 쉽지 않은 일인데 글을 참 잘 쓰셨습니다. 영원한 "을"이란 부분도 가슴이 아프네요.
   어찌보면, 컴퓨터공학에서 우리가 제일 먼저 배워야 할 것은
   어떻게 프로그래밍하느냐 혹은 어떻게 데이터를 모델링하느냐가 아니라,
   
   "어떻게 돈이 되는 소프트웨어 사업을 구상하느냐" 일 지도 모른다는 생각을 해 봅니다.
   
   아마도 개발자들이 인정받으려면, 갑이 정해져 있는 프로젝트를 하는 회사가 아닌,
   다수의 고객이 존재할 수 있는 제품을 만드는 회사의 일원이 되어야 하지 않나 싶습니다.

   • 스맥 반더빌트 2010/01/07 22:17 Modify/Delete

     네 DIFF님, 실세계의 비지니스를 단순 지원 하는 역할에서의 개발은 많은 시간이 흘러도 '을'의 입장을 벗어날 수 없을 듯 합니다.
     
     모든 개발자들의 꿈이 겠죠.
     
     개발된 서비스나 제품 자체가 수익을 만들어 내는 회사의 일원 되는 것.
     
     서로 토론하며 세상의 지식과 정보를 더욱 가치있고 쓸모 있게 만드는 것.
     
     희망합니다. 우리가 개발하는 서비스가 인간이 인간답게 살 수 있도록 지원하는 것이 되기를...

4. 우군 2010/01/12 13:04 Modify/Delete Reply

   제 블로그의 엮인글을 보고 찾아왔습니다. 웹기획을 하는 기획자이자 막 걸음마를 시작한 PM으로서 비단 개발자 뿐 아니라 모든이와의 커뮤니케이션이 얼마나 중요한 요소인지 깨닫고 있는 중입니다. 커뮤니케이션만 잘 이루어져도 반은 먹고 들어갈 수 있을거 같은 생각입니다. 목표를 논리적으로 만족시키기 위한 기획을 위해 부단히도 노력해야겠다는 생각을 추가로 하고 갑니다. 좋을 글 잘 읽었습니다.

   • 스맥 반더빌트 2010/01/12 14:46 Modify/Delete

     우군님이 말씀하신대로 커뮤니케이션이 절반이라고 할 정도로 중요합니다. 문제는 '모든 문제의 답은 어떤 문제의 정답도 아니다'라는 것에 있겠죠.
     
     사람마다 커뮤니케이션에 대한 개념이 다릅니다. "내가 원하는 것은 A라는 것인데 해주세요!" 라고 말 할때는 기대하는 답이 사람마다 다릅니다. "되, 안돼?, 되면 언제까지 되"를 커뮤니케이션의 개념이라고 탑재한 사람들이 너무 많습니다. 그런 이유가 제가 장문의 포스트를 남긴 이유 중 하나이기도 합니다.
     
     인정하긴 싫지만 '좋은 개발자와 나쁜 개발자는 타고 나는 것'이라고 느껴집니다. 같은 이유로 '좋은 기획자와 나쁜 기획자는 정해져 있습니다.' 그렇다고 노력하지 말라는 얘기가 아닙니다.
     
     정확한 고객의 요구사항도 알지 못하고, 자신의 생각도 정확히 묘사하지 못 한 기획서(?: 기획서의 정의가 뭘까요.)를 내밀면서 "됐고!, 되, 안돼? 언제까지 되?"를 외치는 기획자가 많은 것은 문제 입니다.
     
     중요한 것은 '공동의 비지니스 목표를 이루기 위해서 자신의 역할을 최대한 하면서 경청하는 자세' 라고 생각합니다.
     
     커뮤니케이션 할 때마다 "됐고!"의 빈도는 '좋은 기획자와 개발자의 척도'죠.

5. 박제성 2010/01/15 04:40 Modify/Delete Reply

   트랙백을 보고 찾아 왔습니다.
   
   이 분야에 긍정적인면과 부정적인 면을 면밀히 분석하고 생각하여 신중한 진로가 되기를 바랍니다.
6. Tiger Kim 2010/01/15 13:19 Modify/Delete Reply

   트랙백 보고 찾아왔어요. ^^
   블로그 잘 둘러보고 갈께요~ 반갑습니다. :)

[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]

: name

: password

: homepage secret mode

[생각을 적어 주세요~ 댓글은 작은 인연의 씨앗입니다.]

: name

: password

: homepage secret mode