Creating Reports in ASP.Net with Entity Framework

Question

We are looking to add Microsoft Reports - SSRS to one of our internal websites.

The database has all the reporting features installed.

The website is using Entity Framework 4 for all data.

I have been able to create a report using the old fashioned way of creating a DataSet (*.XSD) and this works well.

My question though, is it possible to utilise the existing Entity Framework in the site for the data required by the reports? Rather than having to re-invent the wheel and make a whole DataSet, along with relationships etc..

It's a website and not application, so this (http://weblogs.asp.net/rajbk/archive/2010/05/09/creating-an-asp-net-report-using-visual-studio-2010-part-1.aspx) doesn't seem to apply; I don't see the DataSource (in part 2 of the tutorial)

Update

As a side-note, we would like to steer clear of expensive third-party controls etc.

Also, another way to look at the issue might be to generate the *.XSD from the entity framework entity model; is this possible? It's not ideal though would get us up and running..

Answer 1

Below is a quick sample of how i set the report datasource in one of my .NET winForms applications.

public  void getMyReportData()     {         using (myEntityDataModel v = new myEntityDataModel())         {              var reportQuery = (from r in v.myTable                                    select new                                    {                                        l.ID,                                        l.LeaveApplicationDate,                                        l.EmployeeNumber,                                        l.EmployeeName,                                        l.StartDate,                                        l.EndDate,                                        l.Supervisor,                                        l.Department,                                        l.Col1,                                        l.Col2,                                        .......,                                        .......,                                        l.Address                                    }).ToList();               reportViewer1.LocalReport.DataSources.Clear();             ReportDataSource datasource = new ReportDataSource("nameOfReportDataset", reportQuery);             reportViewer1.LocalReport.DataSources.Add(datasource);              Stream rpt = loadEmbededReportDefinition("Report1.rdlc");             reportViewer1.LocalReport.LoadReportDefinition(rpt);             reportViewer1.RefreshReport();              //Another way of setting the reportViewer report source              string exeFolder = Path.GetDirectoryName(Application.ExecutablePath);             string reportPath = Path.Combine(exeFolder, @"rdlcReports\Report1.rdlc");             reportViewer1.LocalReport.ReportPath = reportPath;              reportParameter p = new ReportParameter("DeptID", deptID.ToString());             reportViewer1.LocalReport.SetParameters(new[] { p });          }     }         public static Stream loadEmbededReportDefinition(string reportName)         {             Assembly _assembly = Assembly.GetExecutingAssembly();             Stream _reportStream = _assembly.GetManifestResourceStream("ProjectNamespace.rdlcReportsFolder." + reportName);              return _reportStream;         } 

Answer 2

My approach has always been to use RDLC files with object data sources and run them in 'local' mode. These data sources are ... my entities! This way, I'm using all of the same business logic, string formatting, culture awareness, etc. that I use for my web apps. There are a some quirks, but I've been able to live with them:

• RDLC files don't like to live in web projects. We create a separate dummy winform project and add the RDLC files there.
• I don't show reports in a viewer. I let the user download a PDF, Word, or Excel file and choose to save or open in the native viewer. This saves a bunch of headaches, but can put some folks off, depending on requirements. For mobile devices, it's pretty nice.
• Since you are not using SSRS, you don't get the nice subscription feature. You are going to build that, if required. In many ways, though, I prefer this.

However, the benefits are really nice:

• I'm using all of the same business logic goodness that I've already written for my views.
• I have a custom ReportActionResult and DownloadReport controller method that allows me to essentially run any report via a single URL. This can be VERY handy. It sure makes a custom subscription component easier.
• Report development seems to go pretty quick, now that I only need to adjust entity partial classes to tweak a little something here or there. Also - If I need to shape the data just a bit differently, I have LINQ.