ASP.NET WebForms Data Binding Solutions - asp.net

I am looking for some easy to use data binding to forms controls. Something that will handle formatting, validation and error handling, something that will handle filling controls from business object/DTOs and vice versa with minimal code. I did use google and have found these two links:
Implementing two-way Data Binding for ASP.NET
Using Reflection to Bind Business Objects to ASP.NET Form Controls
I am curios if there is something newer and more complete.
Are you using FormView or manualy fill controls and variables or something else?

I have always used the standard asp.net DetailsView/FormsView controls along with either SqlDataSource or ObjectDataSource controls to accomplish what you are trying to do. This will allow you to do two-way data binding and with a small amount of coding with template fields you can add validation and formatting.
Take a look at http://quickstarts.asp.net/QuickStartv20/aspnet/doc/ctrlref/data/formview.aspx for more information.

Related

asp.net Pattern for handling View/Edit/Insert situations

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

Is there any performance advantage to EntityDataSource over programmatic binding?

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

Options besides FormView for data binding web forms

I don't much care for the template rigmarole of the ASP.NET FormView web forms control. It seems the only way to access template defined controls is to 'capture' module level references to the wanted controls in the ItemCreated data binding event, for use in other tasks and event handlers.
Ideally I would just like to be able to call set this.DataSource and call this.DataBind on a page, but only the latter is possible through inheritence, and doesn't achieve any of my normal data binding needs.
What else is there besides the hairy, scary FormView control?
There is the DetailsView control which renders a 2 column table to setup a form. Very uniform control though, so there is limited flexibility if you need that.
Are you looking for all .NET framework or also any OSS or third party?
HTH.

Data binding on a simple detail form

I created a simple detail edit form earlier, and decided to data bind some controls on it. Of course, I was told they needed to be on a data bound container. My immediate, rather uninformed choice was a FormView. Is this appropriate? What containers could I use here?
Wrapping my controls in the ItemTemplate of the FormView of course made them inaccessible to my code, forcing me into many FindControls and casts, which is just untidy. I know I can write helpers and extension methods that make this much neater, but I just wanted a quick demo. Am I missing something regarding dealing with templated, and this 'nested' controls in this situation?
Your choices are the FormView or DetailsView controls. The primary difference between them is that DetailsView does all the work for you whereas FormView requires you to create your own templates, thus allowing greater control. As you've discovered, FormView requires using FindControl to access the controls, but the intent with data binding is that you shouldn't need to frequently access the controls directly.

Having different asp.net controls tied to each other by having the same datasource

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.

Resources