onde iria denunciar o código de geração de movimento.

Question

Eu tenho uma solução visual studio com os seguintes projetos:

1. UI
2. DataAccess
3. BusiessLogic
4. BusinessObjects

Agora tenho um monte de código que gera relatórios que são enviados via e-mail ou salvos como arquivos CSV.

Estas ReportGenerators aulas levam em objetos de negócios e ou arquivos de saída ou strings.

qual projeto que você colocá-los em? Estou inclinado em direção a uma resposta, mas queria ver o que os outros acharam?

Answer 1

Gostaria de criar um projeto de relatórios separados. Ele não pertence na UI (Eu presumo que eles executados em segundo plano) - ele é efetivamente um 'relato lógica' camada.

Se você pensar sobre como você pode querer reportng apoio, você pode querer um serviço de backend, mas você pode querer expor os dados através de um serviço web, bem como no futuro. Se você precisa para fornecer aos usuários uma facilidade de comunicação front-end você ligue para a lógica de relatórios como se fosse uma UI normais -> Logic -> arquitetura de acesso a dados.

Além disso, se você separar o seu código de relatórios para fora, então você está livre para extraí-lo para uma camada de informação dedicado no futuro.

Answer 2

A concordar com o post de acariquara - você deve construir-los como relatórios (colocar um sproc por trás dos relatórios se necessário), pelas seguintes razões:

• Você pode executar os relatórios e visualização -los através do ReportViewer ao controle. Isto é bastante simples de fazer.

• Você (e mais importante outras pessoas apoiar a aplicação) pode estender a aplicação com mais relatórios sem ter que liberação outra construção da aplicação. Este é um recurso muito útil se você não quer ser amarrado a apoiar a aplicação.

• Você pode publicar os relatórios através relatando serviços também.

• Você obtém todas as opções de exportação de dados do Reporting Services (Excel, CSV, pdf, etc.) com o Relatório Serviços quadro.