2009-03-09 26 views
9

Gần đây tôi đã có một dự án mà trong đó tôi đã nhận được một số dữ liệu từ hệ thống phần mềm cụ thể đến một portlet. Phần mềm đã sử dụng một cơ sở dữ liệu và tôi đã dành một chút thời gian để mô hình hóa dữ liệu tôi muốn và sau đó tạo một dịch vụ web để portlet của tôi có thể lấy thông tin.Báo cáo so với Mã hóa - suy nghĩ?

Sau đó, nó đột nhiên đánh tôi rằng tôi đã lãng phí thời gian của mình. Tôi nắm lấy BIRT, ném nó vào một portlet, và sau đó chỉ viết một số báo cáo trực tiếp nắm lấy các dữ liệu cần thiết từ cơ sở dữ liệu. Tôi đã được thực hiện vào một buổi chiều.

Tôi hiểu rằng báo cáo là một con đường một chiều, nhưng điều này khiến tôi suy nghĩ. Các công cụ báo cáo có thể rất hiệu quả để tạo báo cáo (duh) từ dữ liệu thực tế của bạn, nhưng khi bạn làm điều này, bạn sẽ bỏ qua mô hình của mình, trừ trường hợp đơn giản không phải là biểu diễn trực tiếp dữ liệu của bạn.

Nếu bạn đang viết một ứng dụng chuyên sâu dữ liệu và yêu cầu khả năng thực hiện báo cáo không tầm thường, bạn có bỏ qua ứng dụng của mình và sử dụng một cái gì đó như BIRT hoặc Crystal Reports không? Làm thế nào để bạn quản lý các công cụ này như là một phần của quá trình tổng thể của bạn? Bạn có xem xét các báo cáo bạn viết như là một phần của ứng dụng của bạn và đối xử với họ như vậy không? Một báo cáo là một cái nhìn và một mô hình và một bộ điều khiển (nếu bạn sẽ) tất cả trong một mớ hỗn độn lớn, làm thế nào để bạn đối phó với và giải thích và kế hoạch cho điều đó?

Câu hỏi được sửa đổi: có thể và thậm chí phổ biến rằng một báo cáo sẽ thực hiện một số phép tính kinh doanh trong thế giới hoàn hảo mà bạn muốn có trong ứng dụng của mình. Điều này có thể dẫn đến sự không phù hợp về thông tin được trả lại cho người dùng. Mặt khác, các công cụ báo cáo giúp việc thu thập và hiển thị thông tin trở nên dễ dàng để thực hiện cách tiếp cận thuần túy và làm mọi thứ từ bên trong ứng dụng. Có bất kỳ kỹ thuật tốt nào để đảm bảo rằng dữ liệu trong báo cáo của bạn khớp với dữ liệu mà bạn có thể hiển thị trong GUI thông thường không?

Trả lời

1

Báo cáo là một phần trong ứng dụng của bạn nhưng vì chúng thường là ý tưởng mạnh mẽ hơn, ví dụ, giao diện người dùng thu thập dữ liệu của bạn, tôi hi sinh độ tinh khiết để thuận tiện/tốc độ phân phối và quay lại "thực" mã hóa ... :-)

Ngay sau khi bạn đã hoàn thành báo cáo, người dùng muốn một báo cáo khác hoặc thay đổi màu hoặc nhóm tùy chọn hoặc lọc nhiều hơn hoặc ... điều gì đó khiến bạn rời xa nội dung ... vì vậy tôi không phá hỏng một đường ruột duy trì sự tinh khiết.

2

Báo cáo là rất quan trọng. Báo cáo chủ yếu là quan trọng để chia sẻ các giá trị được thu thập trong một hệ thống cho người dùng bên ngoài, ví dụ: người dùng không trực tiếp sử dụng hệ thống (ví dụ: quản lý số liệu bán hàng). Vì vậy, báo cáo không chỉ đơn giản là hiển thị các sự kiện và số liệu và là thứ gì đó tập trung vào hầu hết mọi hệ thống thúc đẩy thương mại.

Ít nhất các hệ thống nâng cao hơn cho phép bạn tăng cường chúng: với "điều khiển" có thể tái sử dụng của riêng bạn. Ngay cả một cách trở lại có thể được thực hiện - nếu bạn chỉ cần sử dụng các plugin chính xác. Một khi tôi đã viết một hệ thống để gửi email ra khỏi một báo cáo, bởi vì hệ thống đã không cho phép thay đổi. Nó hoạt động - mặc dù nó không có nghĩa là để được sử dụng theo cách đó;)

Báo cáo tạo một phần tốt của ứng dụng và bạn nhận được nhiều tự do nếu bạn tạo báo cáo có thể thay đổi cho khách hàng của mình. Đôi khi bạn có nhiều khả năng hơn là bạn nghĩ đến khi bạn xây dựng hệ thống ngay từ đầu.

Vì vậy, có, cho tôi báo cáo là một phần của hệ thống.

1

Đây thực sự là một dòng tiền phạt. Bạn không muốn tốn quá nhiều thời gian xây dựng các báo cáo (người dùng muốn bạn thay đổi mọi lúc) nhưng bạn không muốn lặp lại logic bằng cách đặt logic nghiệp vụ vào báo cáo của mình!Với các sản phẩm báo cáo của chúng tôi tại Data Dynamimcs, tôi nghĩ rằng chúng tôi đã đạt được một phương tiện hài lòng giữa hai sự cân bằng này.

Bằng cách sử dụng ObjectDataProvider (xem liên kết bên dưới để biết thêm thông tin), bạn có thể liên kết báo cáo trực tiếp với đối tượng nghiệp vụ (đối tượng cũ cũ) để bạn không phải bỏ qua lớp kinh doanh để nhận dữ liệu. Đồng thời, chúng tôi cung cấp một cách để tham khảo và sử dụng các chức năng từ các thư viện khác trong báo cáo của bạn. Bằng cách này nếu bạn đã cấu hình một số mã để thực hiện một số phép tính logic nghiệp vụ, bạn có thể sử dụng lại các hàm đó ngay trong báo cáo của mình. Bạn cũng có thể xem ví dụ về điều này trong các liên kết bên dưới.

Scott Willeke

liệu Dynamics/GrapeCity

1

Cách tôi luôn làm việc với báo cáo là xem xét một phần báo cáo như là một phần của cơ sở mã và được lưu trữ trong nguồn cùng với ứng dụng. Trong một số ngữ cảnh, báo cáo quan trọng hơn ứng dụng, trong quản lý đó đưa ra quyết định kinh doanh khỏi dữ liệu báo cáo, có thông tin sai có thể khiến chúng hủy một dòng sản phẩm, hủy chiến dịch hoặc kích hoạt nhân viên bán hàng. Rõ ràng, điều này phụ thuộc rất lớn vào việc quản lý và ứng dụng của bạn.

Về việc giữ cho mô hình của bạn nhất quán, đây là một câu hỏi phức tạp hơn một chút. Một cách để đảm bảo mô hình nhất quán giữa các báo cáo và ứng dụng của bạn là sử dụng các thủ tục được lưu trữ (hoặc các khung nhìn) để lấy dữ liệu, tùy thuộc vào kiến ​​trúc của ứng dụng của bạn.

4

Tôi thấy báo cáo chỉ đơn giản là một chế độ xem khác trên dữ liệu chứ không phải chế độ xem/mô hình/bộ điều khiển trong một (tốt, có thể là chế độ xem và bộ điều khiển trong một).

Chúng tôi có báo cáo của chúng tôi (được xây dựng trong dịch vụ báo cáo sql 2008) sử dụng dịch vụ trong lớp ứng dụng của chúng tôi để nhận dữ liệu (tuân theo tiêu chuẩn của chúng tôi, truy cập dữ liệu đó nằm trong kho lưu trữ). Các chức năng này có thể thực hiện một truy vấn đơn giản hoặc xử lý việc xử lý rất phức tạp, đó sẽ là một cơn ác mộng trong môi trường báo cáo của bạn hoặc một thủ tục được lưu trữ. Trong thực tế, chúng tôi thấy điều này không mất quá thời gian để mã hóa một số quy trình được lưu trữ một lần, khi hệ thống của bạn phát triển và phát triển, trở thành một cơn ác mộng để duy trì.

Việc xử lý báo cáo đơn giản là một lần duy nhất hoặc không tích hợp vào thiết kế ứng dụng của bạn là một sai lầm lớn.

Các vấn đề liên quan