Data binding vs. setting variable values 2

[Chopstik]

As part of the initial workup on converting (or, for that matter, whether to convert) an existing ASP Classic application over to .NET, we are divining several questions that perhaps someone can offer some direction.

In our existing app, we have all of our data access and business logic code in a separate VB component that we can call from the page whenever needed. Just to ensure that it worked, I converted that component over to VB.NET and then compiled it to use within our testing environment and all works ok. Each page will call the component to return a dataset and then we use the dataset to populate the variables we need on the screen. Because of formatting issues, we did not originally think that a datagrid would be sufficient for our purposes. However, there have been some second thoughts on this issue and I am now looking for additional feedback.

Is there a significant difference between returning a dataset from the component and then manually setting the variable values on the page and just using a datagrid that will bind to the returned dataset? Corollary issues will include going back and updating values when the user needs to do so. Currently, we manually code the SQL string to run the update command independently in the component (values are passed back to the component via an array from the page); again, as opposed to using the binding functionality to perhaps make this somewhat easier. Additionally, the datasets being returned and edited are derived from complex SQL strings that impact several tables within a highly constrained database. This may or may not pose issues, but whereas I have grown more comfortable with the manual procedures previously developed, if there is another (simpler/better) method, I am not opposed to working with it.

Any feedback is greatly appreciated. If this needs further clarification, I can provide that as well. Thanks!

------------------------------------------------------------------------------------------------------------------------
If you don't have a sense of humor, you probably don't have any sense at all.
- Anonymous

 

[link9]

You will take a hit using the DataGrid. However, you will find that the time you save coding the UI is well worth the performance hit that you will take. I take my lumps w/ a big smile on my face.

The performance hit will be lessened further w/ the Framework 2.0 enhancements to the ViewState. It is going on a big diet, and you're finally able to separate out your Event Handling ViewState from your actual data ViewState, which is a big problem that ViewState has right now (ie. you cannot disable ViewState if you want features like Edit/Sort, etc... regardless of whether or not you plan on repopulating on every postback).

I still suggest, however, that you keep your data access separate from the page. You should still have a completely separate assembly (or at the very least... class) handling all of your data updates.

We have classes that represent the business objects, which are called by the UI, which in turn call on database procedures that do the actual database work. Pretty standard n-tiered approach (which is so much more elegant in .NET than it ever was in clASP). That sounds like what you have going there, as well.

The datagrid makes this completely (or rather mostly) seamless because we can create IEnumerable objects that can bind directly to the DataGrid. Here is a good article that shows the basics on this technique. I'm sure you'll find it very useful and intuitive once you get going w/ it:

http://www.flws.com.au/showusyourcode/codeLib/code/CustomCollections.asp?CatID=5

Set your DataKeyField on the DataGrid to the PK in your database, and you have everything you need when your OnDelete/Update/Modify events are called:

protected void OnModify(....)
{
string pk = e.Item.DataKeys[e.Item.ItemIndex].ToString();
BusinessObject myBusinessObject = BusinessObject.GetInstance(pk);
~~~~~~
//Set your properties
~~~~~~
myBusinessObject.Modify();
}//OnModify

etc...

DataBound controls (and especially the DataGrid) are one of my favorite features in .NET. You'll find that with experience and a bit of ingenuity, there really aren't many design problems you cannot conquer using the DataGrid.

Let me know if you have any more specific questions.


paul

The answer to getting answered -- faq855-2992

 

[chiph]

Chopstik -
You might want to browse thru the history of some forums (here, C#, VB.NET, etc) to see which method other people have the most problems with.

I already have an opinion on the subject, but you might want to arrive at yours independently.

Chip H.


____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Chopstik]

Thank you for the feedback. [ignore]link9[/ignore], (sorry, but I did not receive notification of your post earlier else I would have responded earlier,) I am not completely against using the DataGrid, but there are a couple of issues that I've yet to work out (but slowly getting there). One main issue that I forgot to mention earlier is that many times the data I'm returning is a single record and then formatting that data so that it is returned in a tabular format - something that I have not found the DataGrid conducive to easily working with. It may be, but I've not yet come across it, anyway. In cases where I am returning search results, however, this would be fine. In either case, I am still working with it.

I guess part of the reason I ask about this is because we had an n-tiered approach in ASP Classic and while it worked well ok, I want to still be able to take full advantage of the .NET environment and tools. This is one of those instances where I probably do not have enough info at my immediate disposal to know for certain so was trying to get some other input. Essentially, do I just port everything over as-is (with only the immediate syntax changes between the different environments) or try to use some of the GUI tools which some have recommended (while I am more accustomed to coding everything by hand for control issues)?

chiph, I have been browsing both through TT and external resources trying to get ideas on which approach would be better. I would be interested in your opinion and can assure you that I will still find my own independently. (My better half would suggest that is a result of never listening to others...) ;-)

Thanks again!

------------------------------------------------------------------------------------------------------------------------
"I am not young enough to know everything."
Oscar Wilde (1854-1900)

 

[link9]

Personally, I never fully embraced the power of the .NET DataSet. Setting the UpdateCommand and DeleteCommand properties just made me feel like I was giving up too much control. Because of that, I can't really speak to the advantages you can gain by using those methods.

I have seen quite a few very nice examples of strongly typed DataSets used to represent business objects. I assume that's what you're referring to:

http://www.google.com/search?client...n&q=strongly+typed+dataset&btnG=Google+Search

Otherwise, apart from your standard tiered approach to software development, I'm not sure what you're getting at with the "GUI tools" that have been suggested to you. Surely, no one is suggesting that you drag-n-drop a connection on to your page or anything, are they? VS provides some really slick (and really bad) tools that do nothing but promote bad software design.

The VS hype of "no code" sort of gives me the willies. Steer away from that type of stuff. The only thing you should be dragging & dropping onto the page in any application are the various UI elements that make up your interface.

Does this help, or have I missed your point?

-paul

ps. chiph, I'd also be interested in your opinion on the DataGrid. ;-)

The answer to getting answered -- faq855-2992

 

[Chopstik]

Paul,

I'm too much of a control freak to use the drag-and-drop functionality offered within VS.NET (or any other, for that matter), at least not without serious reservations. I guess I was just trying to see if using the datagrid and binding my data was the right answer. In my case, I think the answer is: sometimes. Because most of my pages involve only a single record that must be visually structured a certain way (tabular, as I mentioned before), the datagrid would not work in those instances. I would simply return a dataset and set the individual control values using the dataset. However, for search results pages, the datagrid is probably the best option. Should be fairly simple. Not to mention the nice page functionality (that I'll probably modify somewhat).

Thanks for your input. It's greatly appreciated!

------------------------------------------------------------------------------------------------------------------------
"I am not young enough to know everything."
Oscar Wilde (1854-1900)

 

[chiph]

I come from an enterprise systems background (at my last job, we had a site with 5 million hits per day), and when you get that level of traffic, you want a lot of control over how your data gets handled.

With the DataAdapter, DataSet, and bound controls, you lose a lot of opportunity for tweaking your code for performance. So I've always done direct ADO.NET SQL calls to the database -- your typical CRUD operations, plus the data operations that are specific to the application.

That being said, bound controls are fine for prototypes, and applications that see only occasional use. However, as everyone knows, sometimes the worst thing that can happen to your code is for it to become popular. An app you wrote as a one-off for a specific workgroup or department, is now expected to work for the entire company.

The areas that you want to compare between the two technologies are:

1. Validation of user-entered data (and the feedback to them when they get something wrong)
2. Transfer of the data across application layers (assume a layer will be running on a remote computer)
3. Ease of doing performance monitoring and tuning
4. Date & Currency handling (they need two representations -- one for storage and one for display, for each datapoint).
5. Ease of doing team development (can you create a call interface, and let two teams work independently on both sides?)
6. Ease of writing unit tests
7. Ease of code maintenance (80% of software costs are from maintenance, not new development).

Chip H.

____________________________________________________________________
Click here to learn Ways to help with Tsunami Relief
If you want to get the best response to a question, please read FAQ222-2244 first

 

[Chopstik]

Chip,

That is a well-thought out analysis. Personally, I think that would make a good FAQ for others who may just be starting out like myself wondering on the best approach.

In my own case, I manually code the SQL for which I then use the DataAdapter and DataSet only to return the data to the page from the component. I then set the control values manually instead of binding them (as I mentioned in my previous post). I think I have more control over my app, but I will do some additional research into ADO.NET to see about direct calls (since I'm not sure where/if there is a difference from what I currently use/do) to the database. Thank you for your insight!

------------------------------------------------------------------------------------------------------------------------
"I am not young enough to know everything."
Oscar Wilde (1854-1900)