MVC 모델의 회귀

.NET Framework의 대가와 MOSS 2007 프로그래밍의 대가들이 구축한 소스에 특정 사이트에 맞게 일부 커스터마이징되고 알지 못할 사람들이 이런 저런 업데이트를 가한 소스를 보고 있다. 이 코드가 Package라는 이름이 붙은게 조금 웃기는 사실이긴 하지만, base가 대가들이 만든거니 뭔가 특이하고 신기하긴 하다.

그런데, 도통 이해가 안되는 것 있다.
MOSS 2007 프로젝트를 하다가 보니 공통이라는 모듈 개념에 DAC(Data Access Component)와 BIZ(Business Logic Module)이 포함되어 이 둘이 Component 라는 형태로 붙어 있다. 그런데 이 모듈을 업데이트 하신 분은 DAC는 반드시 BaseDAC을 상속 받아야 되고 BIZ는 BaseBIZ에 상속 받아야 하는 강박관념에 빠지신 것 같다.

물론 DAC의 특성상 Database와 연관되는 작업이 많으니 BaseDAC을 상속 받아 기본 데이터베이스 연결에서는 반드시 쓸 필요가 있을지 모르겠다. 그런데 이 BIZ 부분은 도통이해가 안된다. 최소한 내가 예전에 배웠던 MVC(Model - View - Control) 부분의 Control 정도로 알고 있다. Workflow가 될 수 있고, 단순 계산 처리도 있을 수 있다. 그런데, 꼭 BaseBIZ를 상속 받고 Transaction을 태워야 될까? 크리티컬한 데이터라면, 반드시 All or Nothing을 추구해야 하는 데이터라면 반드시까지는 아니지만 태워야 하는게 기본이라고 생각한다. 하지만 단순한 계산이나 단순한 데이터인데 꼭 태워야 될까?

지금 로직들을 보고 있으면 참 답답한 마음이 그지 없다. 그냥, 적당히 분류해서 계통에 맞게 분리해서 모듈을 구성했으면 간단한 것을 이리 꼬아 저리 꼬아 놓으니 어느 순간에 순환 참조(참조가 계속 연결되어 자기 자신으로 돌아오는 참조)가 되어 그 고리를 끊기 위해 어셈블리(DLL)를 분리하는 불상사가 벌어진 것 같다. ( 해당 어셈블리(DLL)에 클래스 달랑 2개 들어 있다. 굳이 분리해서 따로 구성할 필요도 없는 그런 모듈인데....)
더 웃긴건, DAC이 있는데, Database 접근하는 모듈이 View에 해당하는 어셈블리에 담겨 있다. 왜 DAC을 만든건지.....

대가들이 만든걸 어설픈 누군가가 망친건지.. 아니면 대가 분들이 너무 오바해서 생각들을 하신 건지... 단순하게 만들어서 간단하게 끝낼 수 있는 것을 무쟈게 힘들게 짜놨다. 이제 슬슬 어느정도 그림이 그려지고 있는 판국이라 다행이긴 한데, 이걸 언제 정리해야 하는지는 도통 모르겠다.

UPDATE :
처음에는 프로젝트 수정작업을 할까 했지만, 이미 관계가 얽히고 섥혀 있어 대규모 공사가 되버릴 것 같다. 이 공사 하면 10중 8,9는 PM이 버럭 모드 들어갈 것 같다. GG. GG. 내비두자. 내버려 두자.