llblgen v2.5 built 4/23/2008 vs2008, dotnet 3.5

I have 2 options, 1. using formview with llblgendatasource2, 2. using textboxes with spring.net to bind xxxentity object to the textboxes.

Option #1 is wizard like, easy to use since llblgendatasource2 works with formview to manage the entity status (new or update) and can cache the entity in stateview or session. Nice. However, my concern is the formview may be too heavy for the internet.

Option #2 is simple and robust except that whenever I update an existing record I have a hard time in maintaining the entity fields and flag it as dirty or fetched or new. Also, after updating the entity I have to refetch it and bind it's fields to the text boxes manually.

So here are my questions: 1. Does formview add that much overhead to the point that it is should be avoided (for a typical page that has one formview with about 50 fields? 2. If I use Spring.NET to bind the regular text box to xxxentity (generated from llblgen designer), must I manage the state of the entity manually or is there a way to bind llblgendatasource object to regular text boxes?

Thanks

BZ

To be honest, I haven't used Spring.Net too much (just some little tests). So from my perspective, I don't see any obvious overhead in using one or other.

Do you plan to use ViewState on the FormView? and... How do you measure the overhead?

The overhead I was referring to is more on the ViewState since the majtle neck I see is the internet traffic. There are times I was able to turn off the ViewState in the formview but there are time I wasn't able to. It complains about the ViewState tree being inconsistent or something like that. My experience with FormView is it is somewhat unpredictable. I have read on many forums that one must be careful with the FormView viewstate and control tree, especially on the complicated formview.

Spring.NET allows one to bind the regular textbox control to an entity so there's no formview required. This article, http://www.llblgen.com/tinyforum/NewMessage.aspx?ThreadID=14250&StartAtMessage=0, also offer an equivalent feature.

The problem I have when I use this with llblgen generated entity is that I have to save the entity in either viewstate or session and manually loop through the fields in then entity to see which field needs to be udpated when I update the entity. I probably need to mark the entity and the appropriate fields as dirty! Basically I have to manually do what llblgendatasource2 normally would do!

BZ

I've seen the FormView used in many heavy traffic web-applications, without any performance issues.

You can check and test our ASP.NET 2.0 databinding example

Description: This example shows, using SqlServer's Northwind database, how the LLBLGen Pro datasource controls for both Adapter and SelfServicing should be used in various scenarios and all kinds of different webforms. Comes with two variants: one Ajax enabled and one normal, non-Ajax based.

Thanks Walaa.

OK so lets say that as far as performance is concern FormView does not add that much overhead. There are other issues that FormView does have as mentioned in the article that I posted in the previous message. Many times it is desirable to handle the error in the CUD process and FormView often hide things so it is not possible to handle the error in a certain way.

So lets say that I want to use Spring.NET or some other control to bi-directionally bind the text boxes to the entity. Since I cannot use llblgenprodatasource2, I must manage the entity state manually?

Thanks

BZ

I don't know much about Spring.NET, but hee are some threads where the name spring.NET was mentioned: http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=4795 http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=11245

bunzee wrote:

Thanks Walaa.

OK so lets say that as far as performance is concern FormView does not add that much overhead. There are other issues that FormView does have as mentioned in the article that I posted in the previous message. Many times it is desirable to handle the error in the CUD process and FormView often hide things so it is not possible to handle the error in a certain way.

So lets say that I want to use Spring.NET or some other control to bi-directionally bind the text boxes to the entity. Since I cannot use llblgenprodatasource2, I must manage the entity state manually?

Thanks

BZ

Yes you have to do that. The entities used to render the page are lost after the page is done, unless you store them somewhere, like viewstate or session. When a postback is issued, the entities should be pulled from this source and edited instead.

As it was a lot of work to write the datasourcecontrols, I really don't see a point in re-doing that all over again...

As for performance... a couple of formviews are really not going to give a dent in the performance curve. If you are so concerned about that, do some profiling. The asp.net controls are heavy sometimes but it won't make your page inflate tremendously (just keep an eye on viewstate) and cpu wise, I don't think it will matter much (as asp.net generates C# code from the controls which is compiled into its own assembly)