Отчетность против кодирования - мысли?

Question

Недавно у меня был проект, в котором мне нужно было передать некоторые данные из конкретной программной системы в портлет. Программное обеспечение использовало базу данных, и я потратил немало времени на моделирование нужных мне данных, а затем на создание веб-службы, чтобы мой портлет мог получать информацию.

Тогда меня вдруг поразило, что я трачу впустую свое время. Я схватил BIRT, бросил его в портлет, а затем просто написал несколько отчетов, которые непосредственно взяли необходимые данные из базы данных. Я закончил после обеда.

Я понимаю, что отчетность - это улица с односторонним движением, но это заставило меня задуматься. Инструменты отчетности могут быть очень эффективными для создания отчетов (дух) из ваших реальных данных, но когда вы делаете это, вы обходите свою модель, которая, за исключением простых случаев, не является прямым представлением ваших данных, поскольку они существуют в вашей базе данных.

Если вы пишете приложение с интенсивным использованием данных и вам требуется возможность составлять нетривиальные отчеты, обходите ли вы свое приложение и используете что-то вроде BIRT или Crystal Reports? Как вы управляете этими инструментами как частью вашего общего процесса? Считаете ли вы отчеты, которые вы пишете, частью вашего заявления и относитесь к ним как к таковым? Отчет - это представление, а модель и контроллер (если хотите) - все в одном большом беспорядке, как вы справляетесь с этим, интерпретируете и планируете это?

Пересмотренный вопрос: возможно и даже распространено, что отчет будет выполнять некоторые бизнес-вычисления, которые в идеальном мире вы хотели бы включить в свое приложение. Это может привести к несоответствию информации, возвращаемой пользователю. С другой стороны, инструменты отчетности позволяют собирать и отображать информацию настолько легко, что трудно придерживаться пуристического подхода и делать все из приложения. Существуют ли хорошие методы для обеспечения того, чтобы данные в ваших отчетах соответствовали данным, которые вы могли бы показывать в обычном графическом интерфейсе?

Answer 1

Я рассматриваю отчетность как просто другое представление данных, а не представление / модель / контроллер в одном (ну, может быть, представление и контроллер в одном).

У нас есть наши отчеты (встроенные в службы отчетов SQL Server 2008), использующие сервис на уровне приложений для получения данных (в соответствии с нашим стандартом, что доступ к данным находится в репозитории). Эти функции могут выполнять простой запрос или обрабатывать очень сложную обработку, которая станет кошмаром в вашей среде отчетности или хранимой процедуре. На практике мы обнаруживаем, что это занимает не больше времени, чем написание какой-то одноразовой хранимой процедуры, которая по мере роста и роста вашей системы станет кошмаром для обслуживания.

Относиться к отчетности как к разовому или не интегрированному в дизайн вашего приложения - огромная ошибка.

Answer 2

Отчетность имеет решающее значение. Отчетность в основном важна для обмена значениями, собранными в одной системе, с внешними пользователями, например, пользователи, не использующие систему напрямую (например, управление показателями продаж). Таким образом, отчетность - это гораздо больше, чем просто отображение фактов и цифр, и она является центральной для почти каждой системы, которая ведет коммерческую деятельность.

По крайней мере, более продвинутые системы позволяют вам улучшать их: с помощью своих собственных многократно используемых «элементов управления». Даже обратный путь может быть реализован - если вы просто используете правильные плагины. Однажды я написал систему для отправки электронных писем из отчета, потому что система не позволяла вносить изменения. Это сработало, хотя и не предназначалось для этого;)

Отчеты составляют хорошую часть приложения, и вы получаете большую свободу, если делаете отчеты изменяемыми для ваших клиентов. Иногда у вас появляется больше возможностей, чем вы думали, когда строили систему.

Так что да, для меня отчетность - это часть системы.

Answer 3

Способ, которым я всегда работал с отчетами, состоит в том, чтобы рассматривать отдельные отчеты как часть базы кода и сохранять в источнике вместе с приложением. В некоторых случаях отчеты важнее приложения, так как руководство принимает деловые решения на основе данных отчета, поскольку неправильная информация может привести к отмене линейки продуктов, отмене кампании или увольнению продавца. Очевидно, это сильно зависит от вашего управления и вашего приложения.

Что касается сохранения согласованности вашей модели, это немного более сложный вопрос. Одним из способов обеспечения согласованности модели между отчетами и вашим приложением является использование хранимых процедур (или представлений) для извлечения данных в зависимости от архитектуры вашего приложения.

Answer 4

Это действительно тонкая грань. Вы не хотите тратить слишком много времени на создание отчетов (которые пользователи все равно хотят, чтобы вы меняли), но вы не хотите дублировать логику, добавляя бизнес-логику в свои отчеты! Я полагаю, что благодаря нашим продуктам для отчетности в Data Dynamimcs мы достигли счастливого среднего между этими двумя компромиссами.

Используя ObjectDataProvider (см. Ссылки ниже для получения дополнительной информации), вы можете привязать отчет напрямую к бизнес-объектам (обычным старым объектам), чтобы вам не приходилось обходить бизнес-уровень для получения данных. В то же время мы предоставляем способ ссылаться и использовать функции из других библиотек в вашем отчете. Таким образом, если у вас уже есть некоторый код, настроенный для выполнения вычислений бизнес-логики, вы можете повторно использовать эти функции непосредственно в своем отчете. Вы можете увидеть пример этого в ссылках ниже.

• Привязка к объектам для ваших данных (см. Раздел «Поставщик объектов»): http://www.datadynamics.com/Help/ddReports/ddrconDataSetAndObjectDataSource.html
• Добавление пользовательского кода в ваши отчеты Пошаговое руководство: http://www.datadynamics.com/Help/ddReports/ddrwlkCustomCode.html
• Использование пользовательских сборок (ссылки на общие библиотеки / библиотеки DLL из вашего отчета): http://www.datadynamics.com/Help/ddReports/ddrconCustomCode.html, и http://www.datadynamics.com/Help/ddReports/ddrtskCreatingAnInstanceMethod.html

Скотт Виллек

Динамика данных / GrapeCity

Answer 5

Отчеты являются частью вашего приложения, но, поскольку они, как правило, являются чем-то, что у пользователя будет иметь четкие представления о, скажем, вашем интерфейсе сбора данных, я бы пожертвовал чистотой для удобства / скорости доставки и вернулся бы к «реальному» кодированию ...: -)

Как только вы сделали отчет, пользователи хотят получить еще один, или изменить цвет, или необязательную группировку, или дополнительную фильтрацию, или ... что-то, что отвлекает вас от более причудливых вещей ... так что я не срываюсь. поддержание чистоты.