2009-03-09 2 views
9

최근 특정 소프트웨어 시스템에서 포틀릿으로 일부 데이터를 가져와야하는 프로젝트가있었습니다. 소프트웨어는 데이터베이스를 사용했고, 원하는 데이터를 모델링 한 후 웹 서비스를 작성하여 포틀릿이 정보를 얻을 수있게했습니다.보고 대 코딩 - 사고?

갑자기 내가 내 시간을 낭비하고 있다는 것을 깨달았다. BIRT를 포틀릿에 넣은 다음 데이터베이스에서 필요한 데이터를 직접 가져온 보고서를 작성했습니다. 나는 오후에 끝났어.

보고가 일방 통행 거리라는 것을 알고 있지만 생각이났습니다. 보고 도구는 실제 데이터에서 보고서를 작성하는 데 매우 효과적 일 수 있지만,이를 수행 할 때 단순한 경우를 제외하고는 데이터베이스에있는 데이터를 직접 표현하는 것이 아니라 모델을 우회합니다.

데이터 집약적 인 응용 프로그램을 작성하고 평범하지 않은보고 기능이 필요한 경우 응용 프로그램을 무시하고 BIRT 또는 Crystal Reports와 같은 것을 사용합니까? 전반적인 프로세스의 일부로 이러한 도구를 어떻게 관리합니까? 귀하가 작성한 보고서를 신청서의 일부로 간주하고 그러한 보고서를 그러한 것으로 간주합니까? 보고서는 하나의 커다란 혼란 속에서 하나의 뷰와 모델 그리고 컨트롤러 (만약 그렇다면)입니다. 어떻게 다루고 해석하고 계획합니까?

수정 된 질문 : 보고서가 완벽한 세상에서 귀하의 신청서에 포함되기를 원하는 비즈니스 계산을 수행하는 것이 일반적 일 수도 있습니다. 이로 인해 사용자에게 주어진 정보가 일치하지 않을 수 있습니다. 반면보고 도구를 사용하면 정보를 수집하고 표시하기가 쉽기 때문에 순수한 방식을 취하고 응용 프로그램 내에서 모든 작업을 수행하기가 어렵습니다. 보고서의 데이터가 일반 GUI에 표시되는 데이터와 일치하는지 확인하는 데 유용한 기술이 있습니까?

답변

1

보고서는 앱의 일부이지만 일반적으로 데이터 캡처 UI보다 사용자가 강한 아이디어를 갖기 때문에 편의성/배송 속도를 위해 순도를 희생하고 '실제' 코딩 ... :-)

보고서를 완성하자마자 사용자는 다른 것을 원하거나 컬러 또는 선택적 그룹 또는 더 많은 필터링을 변경하거나 ... whizzier 자료에서 벗어나는 것을 ... 그래서 나는 순결을 유지하는 용기를 꺾지 않는다.

2

보고가 중요합니다. 보고는 한 시스템에서 수집 된 값을 외부 사용자와 공유하는 데 가장 중요합니다. 시스템을 직접 사용하지 않는 사용자 (예 : 판매 수치 관리). 따라서보고는 사실과 수치를 표시하는 것 이상의 의미가 있으며 광고를 유도하는 거의 모든 시스템의 중심입니다.

적어도 더 진보 된 시스템은 자신 만의 재사용 가능한 "제어 장치"를 사용하여 향상시킬 수 있습니다. 올바른 플러그인을 사용하는 경우에도 다시 돌아갈 수 있습니다. 일단 시스템이 변경을 허용하지 않았기 때문에 보고서에서 이메일을 전송하는 시스템을 작성했습니다. 그것은 효과가 있었지만, 그런 식으로 사용 되려는 의도는 아니었지만)

보고서는 응용 프로그램의 좋은 부분을 차지하고 보고서를 고객에게 변경 가능하게 만들면 많은 자유를 얻습니다. 때로는 시스템을 처음 만들 때 생각했던 것보다 더 많은 가능성을 생각해내는 경우가 있습니다.

그래서 네,보고는 시스템의 일부입니다.

1

참으로 훌륭한 라인입니다. 보고서를 작성하는 데 너무 많은 시간을 소비하고 싶지는 않지만 (사용자가 항상 변경하기를 원함) 비즈니스 논리를 보고서에 추가하여 논리를 복제하고 싶지는 않습니다!Data Dynamimcs의보고 제품을 사용하여 이러한 두 가지 단점 사이에서 행복한 매체를 발견했습니다.

ObjectDataProvider (자세한 정보는 아래 링크 참조)를 사용하면 보고서를 비즈니스 개체 (일반 오래된 개체)에 직접 바인딩 할 수 있으므로 데이터를 가져 오기 위해 비즈니스 계층을 우회 할 필요가 없습니다. 동시에 보고서에서 다른 라이브러리의 기능을 참조하고 사용할 수있는 방법을 제공합니다. 이렇게하면 비즈니스 로직 계산을 수행하도록 이미 구성된 일부 코드가있는 경우 해당 함수를 보고서 내에서 직접 다시 사용할 수 있습니다. 아래의 링크에서이 예를 볼 수 있습니다.

스콧 Willeke

데이터 역학/그레이프 시티

1

보고서를 작성한 방법은 부분 보고서를 코드베이스의 일부로 간주하고 응용 프로그램과 함께 소스에 저장하는 것입니다. 일부 상황에서는 보고서가 응용 프로그램보다 중요합니다. 즉, 잘못된 정보로 인해 제품 라인을 취소하거나 캠페인을 취소하거나 판매원을 해고 할 수 있으므로 보고서 데이터에서 비즈니스 결정을 내릴 수 있습니다. 분명히 이는 관리 및 응용 프로그램에 크게 달려 있습니다.

모델을 일관성있게 유지하는 것과 관련하여 이는 약간 까다로운 질문입니다. 보고서와 응용 프로그램 간의 일관된 모델을 보장하는 한 가지 방법은 저장 프로 시저 (또는 뷰)를 사용하여 응용 프로그램의 아키텍처에 따라 데이터를 검색하는 것입니다.

4

하나의보기/모델/컨트롤러 (물론보기 및 컨트롤러 중 하나 일 수도 있음)가 아니라 단순히 데이터에 대한 다른보기로보고합니다.

우리의 보고서 (SQL 2008보고 서비스에 내장되어 있음)는 응용 프로그램 계층의 서비스를 사용하여 데이터를 가져옵니다 (표준에 따라 데이터 액세스가 리포지토리에 있음). 이러한 함수는 간단한 쿼리를 수행하거나보고 환경이나 저장 프로 시저에 악몽이되는 매우 복잡한 처리를 처리 할 수 ​​있습니다. 실제로 이것은 시스템이 성장하고 성장함에 따라 계속 유지되는 악몽이 될 수있는 일회성 저장 프로 시저를 코딩하는 것보다 더 오래 걸리는 것을 발견했습니다.

보고서를 일회성으로 처리하거나 응용 프로그램 디자인에 통합하지 않는 것은 큰 실수입니다.