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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

• Привязка к объектам для ваших данных (см «Provider Объект» раздел): 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 4

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

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

Answer 5

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

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

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