OK, I think I'm getting mad here...
I thought this should be super simple, but I just can't figure out how to do that.
This is what I'm trying to do:
I want to create an rdlc report using the ReportViewer control in ASP.NET 4 (VS 2010), and, as its datasource, use a class with some properties.
I tried everything I can think of, but I just can't figure this out. All the docs I found state that the object should appear in the DataSource pane of the website, but I can't make it appear there.
I would like the fields of the class to appear in the report desiger so I can use them - but I can't do that either.
Using the designer, I can only define new dataset - I don't want to use dataset, but business objects!
So - how can I do that? Do I have to use some kind of DataSource control? How can I make the report designer know about the business object?
Thanks!
Memi
did you follow this tutorial?
everything you must do is:
define your DTO classes or generate it using EF4 (for example)
define your business classes with some methods (like GetAll...)
build your solution (that's important)
now from your report designer you can choose methods from business classes as dataset and drag and drop field from the DTO classes
when you choose that report to display in the reportviewer, the datasource object will be added for you
I found this blog very helpful.
When you create a new datasource for your rdlc, in the Dataset Properties dialog:
1) In the Data source drop down, select the namespace that contains the class which contains the public method (see #2).
2) In the Available datasets drop down, select the public method that returns an IQueryable of your business objects.
Is your business object class marked as public? I've seen in a video that it must be public.
I have the same problem and found a way around it. For some reason if you develop a ASP.NET application Microsoft took away add new datasource functionality. The way around is not great but it does work. I use all objects and I use the Enterprise library and I want to use my objects for my reports it only makes sense why they don't enable you to do this. I have no idea why Microsoft would not allow this functionality for web apps.
But that leaves windows apps it works so what I did was create a separate windows project include my objects that I want to bind to in that project and create the report on the forms project. I then bring that report into my Asp.net web app and call it through code. Here is a few pieces of code that I use to do this. This is in VB but could be converted to C#. I also have a drop down list that selects the report that is needed and a case statement that gets the data.
Private Sub LoadReport()
Try
pnlReport.Visible = True
Dim Dal As New DataAccess
Dim objRptOutputData = New Model.RptClientCollection
Dim lr As LocalReport = OutputReportViewer.LocalReport
Dim rds As New ReportDataSource
lr.DataSources.Clear()
OutputReportViewer.Visible = True
OutputReportViewer.ProcessingMode = ProcessingMode.Local
OutputReportViewer.LocalReport.EnableHyperlinks = True
Dim SelectedReport As Integer = 0
If Me.ddlReport.SelectedItem.Value IsNot "" Then
SelectedReport = Me.ddlReport.SelectedItem.Value
End If
Select Case SelectedReport
Case ConstantEnum.Reports.ActiveWaitingList
objRptOutputData = Dal.GetRptClientsByStatus(ConstantEnum.Status.ActiveWaitingList)
lr.ReportPath = "Reporting\Report1.rdlc"
rds.Name = "dsClient"
rds.Value = objRptOutputData
Me.lblCount.Text = "Count: " & objRptOutputData.Count
Case ConstantEnum.Reports.InactiveWaitingList
' This is a small app I have about 15 case statements if it was bigger I would of done this selection a bit different.
End Select
lr.DataSources.Add(rds)
lr.Refresh()
OutputReportViewer.DataBind()
Catch ex As Exception
ExceptionUtility.SendError(ex, "Reports", "LoadReport")
End Try
End Sub
Have you seen this earlier version? Is this what you need:
http://msdn.microsoft.com/en-us/library/ms252073(v=VS.80).aspx
Related
Forgive me if this is a really dumb question. I have a ASP.NET Code First Application (VB.NET 4.6) using DataContext in which I can use a syntax like this:
Dim db As New MyDataContext
Dim id As Integer = 123456
Dim clientRec = db.Clients.Find(id)
So now I am building a backend WinForm support for the ASP.NET FrontEnd and can't seem to find the right combination of references to make this work, OR if it is even possible. It seems like the DB commands are different in Windows Forms. I'm used to building WinForms so sure there are workarounds but I don't understand why there are differences and how I could close the gap if possible in order to use a similar command set. Thanks in advance for setting me straight!
I have experience with webForms and now i am starting to learn MVC, oh boy....everything looks so different. Since my background is webForms, I just want to make sure If am doing this properly. I am pulling data (Queries, Stored Procedures etc) from MS SQL Server & Goal is to represent them within view. here is what I have done so sar.
Here is my Model
Class Product ' Just a Template
private _title
private _price
' property implementation etc
End Class
Class ProductModel ' Returns Actual Data
Function getProducts as list(of product)
' use SqlDataReader to Execute the Stored Procedure
' Populate a list(of product)
' list.add(new product(title,price))
' Return the List
end function
Function getTopProducts() as list(of products)
End Function
End Class
Now Here is my ProductsController index() ActionMethod.
Dim p as new ProductModel
return view(p)
Then within my View (Which is strongly typed for ProductModel Class), I am using a For each on Model.getProducts or Model.getTopProducts and showing the data on screen.
Now Few questions...first of all, is my approach reasonable? is it a standard way of setting up Models with MVC? If not then please correct me.
Secondly, all the examples I see online, i see people using LINQ, EF etc....however in my environment performance is very important, and i am almost always returning data using Stored procedures, so is it OK to use pure ADO.NET or using LINQ/EF can help me out in some way?
...is my approach reasonable? is it a standard way of setting up
Models with MVC? If not then please correct me.
Yes, it's best practice to use a viewmodel than work with your entities directly on your views.
is it OK to use pure ADO.NET or using LINQ/EF can help me out in some
way?
It's perfectly fine to use pure ADO.NET if you feel doing all the dirty works an ORM provides.
You approach is the one that is mostly shown when you learn about MVC. However, if you want to be a bit picky about naming convention then your ProductModel would be called ProductViewModel. This ViewModel will allow you to pass more information to View than it is available in your Product class (which is your model class). But this is insignificant although you should get used to using View with ViewModels.
As for your second question you can use anything you want as data access technology. Entity Framework is promoted by Microsoft as one of its technologies for manipulating with the information in a database. However, if you want you can use ADO.NET with stored procedures, or you can use RavenDB with its own client interface. It's really up to you.
Recently I dealt with a commercially available ASP.NET product that shall go unnamed. When poking around in the code, I noticed that there was usercontrol casting that looked like this:
Dim ctl As ASP.modules_controls_addressinput_ascx = DirectCast(Me.FindControl("AddressInput1"), ASP.modules_controls_addressinput_ascx)
More recently I needed to cast a usercontrol to its specific type in one of my own projects so I could access its public properties and naturally I copied the casting method from above, since I had not seen another way to do it.
However, when deploying the project with this type of casting it would "Build", but failed when I tried to "Publish" with the error "Unknown Type". After some tinkering, I realized that the type of the declared class would work as follows:
Dim ctl As Modules_Controls_AddressInput = DirectCast(Me.FindControl("AddressInput1"), Modules_Controls_AddressInput)
Where the usercontrol is declared like this in its ascx.vb file:
Partial Class Modules_Controls_AddressInput
Inherits System.Web.UI.UserControl
And indeed, this also fixed the issue with publishing.
My question is what would compel someone to cast the first way vs the second way, especially when it means that publishing the project will fail?
I am not sure but the first approach will cast your control to the compiled code in asp.net temp folder C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files\ProjectName but the second approach will cast it to a the class itself. In my work usually I use LoadControl("UserControlPath") to create an instance of any user control
Dim ctrl As MyControl = CType(Page.LoadControl("MyControl.ascx"), MyControl)
ctrl.Property1 = value1
ctrl.Property2 = value2
for more further information about user controls in ASP.Net you can refer to this post http://msdn.microsoft.com/en-us/library/ms972975.aspx
I am fairly new to ASP.NET and I am trying to figure out how to use the entity framework model to data from a textbox field and store it in an existing field in a database which is available to the application .
I looked around on the internet and some solutions were to use a detailView but that would require me to recode the entire page and I would like to avoid that.
Can anyone provide any inputs on how to go about that ?
Thanks !!
For an introduction to using EF with ASP.NET see the tutorials at http://asp.net/entity-framework/tutorials -- there are two series there for Web Forms and one for MVC. Both of them have examples of using textboxes.
var context = new MyEntities();
var myObject = new myObjectType();
myObject.myValue = myTextBox.Text;
context.myObjectTypes.Add(myObject);
context.SaveChanges();
I am using web forms, C#, Asp.net.
As we all know, in this model UI and business logic are often mixed in. How do I separate these effectively?
The example I would like to use is:
I have a GridView and a DataTable (GridView binds to the DataTable and DataTable is fed from the stored procedure).
I would like the GridView (UI) and DataTable (business logic) to be decoupled.
Is it worth it to write an wrapper for DataTable? Are there practical patterns that have been proved and tested that you could recommend to be followed?
If someone with experience could shed some light, that would be awesome.
And, as a final note I would like to say that ASP MVC is not an option right now, so don't recommend it.
My database access layer returns a DataTable.
Note that I HAVE to use this database layer as this is a company policy.
I went through this recently while decoupling much the same thing from our UI layer.
You can see my progress here and here.
In my opinion, A DataTable does not represent business logic. Specifically, it's data pulled directly from the database. Business logic turns that data into a truly useful business object.
The first step, then, is to decouple the DataTable from the Business object.
You can do that by creating objects and List<object> that make up DataTables and Collections of DataTables, and then you can make a ListView that displays those Objects. I cover the latter steps in the links I posted above. And the former steps are as easy as the following:
Create a class that will represent your object.
iterate through your DataTable (or DataSet, or however you retrieve the data) and shove those fields into properties of that object (or that List<T>);
return that List to the Gridview or ListView to display.
This way your ListView or Gridview won't be tightly coupled to the method that you are retrieving your data. What happens if you decide to get your data from a JSON query or a XML file later on? Then you'd have to build this into there.
Step 1 - Getting Data From Database
There are multiple methods to get data from a database, there's no way I can go through all of them here. I assume that you already know how to retrieve data from a database, and if you don't, there are quite a few links to follow. Let's pretend you've connected to the database, and are using an SQLDataReader to retrieve data. We'll pick up there.
Class Diagram
Foo
----
id
Name
Description
And here's the method:
private void FillDefault(SqlDataReader reader, Foos foo)
{
try
{
foo.id = Convert.ToInt32(reader[Foo.Properties.ID]);
foo.Name = reader[Foo.Properties.NAME].ToString();
if (!string.IsNullOrEmpty(
reader[Foo.Properties.DESCRIPTION].ToString()))
foo.Description =
reader[Foo.Properties.DESCRIPTION].ToString();
else foo.Description = string.Empty;
}
catch (Exception ex)
{
throw new Exception(
string.Format("Invalid Query.
Column '{0}' does not exist in SqlDataReader.",
ex.Message));
}
}
Once that happens, you can return a list by going through that process in a while loop that targets the SQLDataReader.Read() function.
Once you do that, let's pretend that your Foo being returned is a List. If you do that, and follow the first link I gave above, you can replace Dictionary<TKey, TValue> with List<T> and achieve the same result (with minor differences). The Properties class just contains the column names in the database, so you have one place to change them (in case you were wondering).
DataTable - Update Based on Comment
You can always insert an intermediate object. In this instance, I'd insert a Business Layer between the DataTable and the UI, and I've discussed what I'd do above. But a DataTable is not a business object; it is a visual representation of a database. You can't transport that to the UI layer and call it de-coupled. They say you have to use a DataTable, do they say that you have to transport that DataTable to the UI? I can't imagine they would. If you do, then you'll never be de-coupled. You'll always need an intermediate object in between the DataTable and the UI layer.
I'd start by decoupling the data table right into the trash can. Build a domain layer, and then some type of data access layer which deals with the DB (ORM recommended).
Then build a servicing layer which provides the data to the UI. All business logic should be within the service or the entities themself.
Consider implementing MVP (model view presenter) pattern. It gives you separation of biz logic through presenter interface, which also allow better unit testing capabilities. Your codebehind of aspx page is then just connector of events and getter/setter of properties. You can find it in MS pattern&practices enterprise application blocks (CAB - composite application block - if i'm not mistaking).
You can read more about it here: http://msdn.microsoft.com/en-us/magazine/cc188690.aspx
But also going from DataTable/DataSets to objects (POCO) is preferred.