Recently I have noticed about a subtle restriction in GridView's paging mechanism. Efficient paging, loading just requested page of data, is only possible with using DataSource controls like ObjectDataSource that means declarative data binding and is impossible when not using a data source and just from codebehind (MSDN describes it here).
Does this means ASP.NET is based on declarative programming not code behind? And it's better to do declarative programming by default?
Out of the box WebForms tries to steer you down the declarative path. You can get around that and actually write code, but WebForms makes it extremely difficult.
If you really want to have control then you should look into the ASP.NET MVC Framework.
ASP.Net uses both: markup is declarative, code-behind is imperative.
You should favor a style that leads to more declarative code - building user controls, for example. But those controls will still need imperative code that tells them how to behave.
I ended up doing my own paging using the SQL ROWNUMBER function.
select * from
( select row_number() over (order by pk asc) as rownumber, * from ...)
where row_number between #a and #b
I ended up not going declarative at all - instead of feeding a datasource the parameters (which one could feasibly do) I just managed everything in the code-behind, set the datasource manually, built the pager by hand.
The reason I did it that way? A bug in 3.5's querystringfield parameter handling.
I could have probably handled the object data source with row_number, but you don't have to do anything declaratively if you don't care to.
Related
I am an asp.net beginner and thinking about designing a website with a typically Master-Detail view. There is a GridView-Control which is displaying all Records and Detail view below to edit existing records, add new ones and display one in detail.
There are several controls in asp.net which can handle such situations: GridView in combination with DetailsView or FormView. But all these approaches do have in common that they seems to be designed for Rapid application development. I want to use my own DAL and so on, so I need to have full control over Insert/Update statements for example.
Whats the typical asp.net approach for dealing with this?
Should I create a UserControl for the Detail view which saves its state (View/Edit/... mode) on its own? Furthermore the view differs only slightly with its state (for example the Insert view does have one more Input-control than the edit view). It seems that the mentioned DetailsView and FormView cannot handle this either and so I have a lot of copy&paste like code.
I think thats all a pretty common situation. What do you prefer in those situations?
You can bind manually data from your custom DAL to the DetailsView or FormView directly like so:
this.dvw.DataSource = new[] { DAL.GetObject(1) };
this.dvw.DataBind();
Or you can also use the ObjectDataSource, which wires up to your DAL object and invokes the method when it needs it.
You can also use a custom user control and load the data manually, which is an approach I have taken in my applications too.
It really depends on your architecture, what you want to achieve, how complex your object model is, and a variety of other factors.
For the Master part, I build the interface by hand, I mean, creating textboxes, labels, etc.
For the Details part, I use a editable GridView. This a tedious task.
Of course, you can use some scaffolding to generate ASP.Net code for your UI from the database model.
You can check this: http://codepaste.net/b1geac
I'm working on a heavily data driven ASP.NET web forms application. We're using the Entity Framework 4.1 and I'm normally used to going around databinding all of my controls in the code behind. I've been coming across a lot of examples using the EntityDataSource ASP.NET control and am wondering if there is any advantage to using this control as opposed to binding the data on the code behind?
Thanks, J
I always considered "specialized" data sources risky and against properly layered applications. EntityDataSource, SqlDataSource, LinqDataSource, name it, you provide low-level access details in your declarative code. It feels great for a demo website but could potentially raise severe issues in a large one.
Have you instead considered using the ObjectDataSource? It could provide the best of the two - you provide a clean, declarative binding so there's no binding code required yet the DataProvider (or Repository) class which ultimately provides the data has to be written in C#. From such class you can use any data access technology, EF, Linq, SQL, anything.
See the discussion of EntityDataSource vs. ObjectDataSource in
http://www.asp.net/entity-framework/tutorials/using-the-entity-framework-and-the-objectdatasource-control,-part-1-getting-started
There are two primary methods of getting data onto a page when it comes to associating that data to markup using some kind of Repeater; performing data binding in the markup (DataBinder.Eval, etc.) and overriding the OnItemDataBound event, finding the control on the page, and setting the value on the control in the code behind. I have my own opinion and understanding based on the MS-70-528 exam, but I wonder what the consensus here on SO is; what's the "best practice" or "accepted design pattern"? Even when there's some operations to perform on the data being bound.
Try binding in markup as you can, that code is more maintainable than the code in OnItemDataBound. The intention is what ever is the simpler.
The Gridview control in ASP.NET provides updating capabilities when assigning a SqlDataSource control to the Gridview's DataSourceID, however when programmatically assigning a code level SqlDataSource to DataSource, the built-in updating capabilities go away and you are forced to roll your own. Why? What is the difference here, since all we're doing is referring to the SqlDataSource directly, instead of by ID? Why can the GridView still not take advantage of the SqlDataSource UpdateCommand?
Well, the first case, it has 2 native controls. Web and Data. You can perform RAD via VS.NET via their visual and configuration tools. MS ensure that the framework can allow such visual controls to data controls coupling in the aspect of CRUD automatically.
Second case, when you have your own SqlDataSource which is not one of the data controls, you are on your own. That's how it is. I hope someone can tell us a solution for it too.
my 2 cents.
I've discovered that it's possible to programmatically create a SqlDataSource, give it an ID, and assign the properties as follows to allow the built in editing to be mapped properly:
gvData.DataSourceID = dataSource.ID
In Winforms you can have two controls tied to the same datasource in a way that when you select a record in one of them, the same record is selected in the other control.
Something that has always bugged me is being unable to non programatically reproduce this behavior in web development. Is there any way to do this, framework, control toolkit, anything?
You will be able to in ASP.NET 4.0 with Sys.Observer.makeObservable.
The short answer is no.
In order to achieve this result in Windows Forms, the data presenter control (a DataGrid for instance) needs to trigger an event handled by the Datasource that, in turn, (as it keeps a list of all data presenter controls bound to it) order them to rebind.
Although this effect can be reproduced in a web scenario, it's definetly not simple because of a simple fact: It's not single layered. The Datasource is on server.
The framework or control toolkit that would expose this feature would need to create a client representation of the Datasource that would reproduce the process I described in Javascript or other technology.
I personally know Telerik, DevExpress and some other widely used frameworks and I ensure you. " non programatically" you won't be able to do this.