up till now i have always created and bind data source on code behind but now i have seen (and used) object date sources on aspx page and bind right there by mentioning listview DataSourceId. if i just want to display data without any change, does it make any difference? in performance or in term of good practice?
As discussed in one of SO question
asp.net sqldatasource vs doing it in code behind
Embedding your SQLDataSource or any datasource within the asp.net page is coupling your presentation layer with your data access layer resulting in reduced testability and flexibility. I strongly suggest moving your data connections to their own classes and created a data access layer that your code behind pages could then draw from.
Ideally you'd seperate this even further into an N-Tier solution. Link
Some Useful links
populate gridview via code-behind or markup DataSource?
I would say that it depends on size and scalability of project.
If you want power and control then go for code-behind.
If you want ease-of-use and speed then do things on the page and let the object manage the CRUD
I would say you have alot more control over your control if you bind it in the code behind you can manipulate your results in many creative ways. If you do your databinding in the your markup like with a SelectMethod or OnInit. Every postback or reload will put that data back to what you have in that method. Which can be great for populating a drop down menu that you always want to show the same data. If you want your data to be responsive i would say you have to use DataBind() in your code behind.
I would also think this is a best practice for learning to do more advanced things with your data.
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 have an ASP.NET page with a Wizard control containing several pages of form fields. The data is collected and inserted to a database from the code behind page. I need to set this form up so you can not only insert, but edit a record as well. Since the form is long and complex, I would rather use the existing one and not make a duplicate one for editing, especially since I want to keep both forms exactly the same and any edits would have to be made to both. But it looks like this is what I need to do if I'm going to databind it. But this would also involve putting the Wizard inside of a FormView, and then I'd have to use FindControl to access any of the fields which would mean altering all my already-existing code (which of course would be time-consuming). So should I manually enter all the values from the code behind instead of databinding it? Which is better, to use a FormView and have duplicate forms (plus have to go in and redo the way I access the fields), or to do everything from the code behind?
I cheat in this circumstance. :)
Create each screen as 2 separate user controls
One for edit, and one for view
Then you get access to all you usual coding
Then embed the controls into the Wizard/FormView
I would suggest you to Go Ahead using FormView, as using DataBind control you have more control the functionality and layout Insert/Edit/View template. Since you have specified that your form is very complex and long, if you control from code behind you have to do lot of work to handle this in code behind and lot code required.
Since I have personal experience to develope very complex form using FormView and it was easy for me bind the Value in directly in formview instead if you assign/Get Values of each conrol in code behind and sometimes you have to hide.
I haven't seen this implemented before in ASP.NET, but am thinking about a UI that would look and act like this:
Conceptual Overview
A TabControl is loaded and the first tab contains a grid
When a row is double-clicked, a new tab is created with the record detail
The content of the tab/record detail is created by a usercontrol
Many tabs could be created, and therefore many instances of the usercontrol will be created
I know ASP.NET will rename my (runat="server") ID's for me, and that I can use jQuery or ASP.NET server-side code to work with the ID's... My concerns are:
How can I ask ASP.NET to generate a unique ID for each Nth instance of my usercontrol (to be rendered in a placeholder)
How do I actually create that extra instance of the control?
What else do I need to keep in mind?
Since I don't want postbacks I'm considering basing my implementation off of ComponentArt's Callback Control, and using ASP.net usercontrols to achieve this effect. This will allow me to do most things that require a postback, but won't refresh all the elements on a page... just the section that contains the user control. That being said, I'm not tied to a particular implementation.
You should look into the Page.LoadControl method. It works nicely and as far as I remember you put placeholders on your page and load the controls into the PlaceHolders, that's how you control the ids.
One thing that doesn't work out so well with this approach is when your control raises events that your Page object has to handle. If your control is selfcontained however you shouldn't have a problem.
This might help you get started:
http://www.codeproject.com/KB/aspnet/LoadingUSerControl.aspx
See title.
Using ObjectDataSource is associated in my mind with quick demos that you can see at conferences and in video tutorials (which typically tells me "don't do it this way in production").
Also I always like to have control over what's going on and when it happens. My other problem with ObjectDataSource is that is's declarative.
Looking forward for your help and opinions.
UPDATE:
I'm retrieving only one page of results from the database and the GridView.PageCount is read-only [sic!].
Yes, you need to define an PageIndexChanged event handler to perform the actual paging of data from your source before binding to the Data Grid, same idea for sorting but with a SortCommand handler.
I am looking for an example of using ASP.net AJAX to show a 'live' filtering of a repeater control based on what is being typed into a textbox. I have seen stuff using the Web Client Software Factory but am more interested in something that doesn't require an additional library.
The asp.net ajax control toolkit has one here.
If you don't like that one, searching google for "Ajax Autocomplete" gives lots of decent looking results, unless I am mistaking what it is you want to do.
I think you're a little confused as to what AJAX entails. If you want the filtering to interface with the server control's datasource, then it would not by definition be AJAX.
Live filtering a databound control the way you want is ill-advised, I think. For each iteration you'd have to re-bind the control, which would create a tremendous amount of overhead.
You'll need to find a way to do this client-side, with javascript. It could simply hide items within the repeater-created markup as they are filtered out, although how exactly this would be accomplished depends entirely on what html you're generating with the repeater.