C# program approach for remote clients

5tephen

5tephen

5tephen

Associate
Joined
16 Oct 2003
Posts
1,520
A client of mine has just opened a second office and are also wanting me to develop software for them to manage customers and various other records (they're a recruitment agency). The software will end up being used in 4-5 different offices in 12-18 months time.

I am fairly proficient at C# development in conjunction with SQL Server and have written some good stuff with it. Basically there will be gridviews listing potentially hundreds of records at a time, with the option to double-click any one and open it for detailed viewing/editing, and sometimes uploading rtf's/pdf's to the associated record.

I have done next to no ASP, apart from basic dragging and dropping to see what it can do, and creating very slow and bloated apps as a result. With C# and ASP integrating so well, how can I use as much C# as possible to create a solution that will work well over the web, ie. save bandwidth?
Also, a more specific question - are DataSets out of the question for web apps, because of the resources they require, ie. should I use DataReaders?
 
5tephen said:
Also, a more specific question - are DataSets out of the question for web apps, because of the resources they require, ie. should I use DataReaders?
Click to expand...

Probably. I dont really know much about them, but I once worked for a company who wrote large web based apps and they had practically abolished the use of DataSets in the code all together. I think they decided they were badly written and used loads of memory unnecessarily (which obviously translates to using loads of bandwidth if you try and send them!).
 
HTMLHugo said:
whats the score with the saving of bandwith ?
Click to expand...

It's over the web. Surely I have to make cutbacks in functionality to cater for the fact that people are not on a gigabit lan and are now dealing with kilobits?
 
Regarding the question of DataSets vs DataReaders, it really depends on how you're going to use the data.

For example, if you simply want to run through a list of records and display the output, without any facility to track back through records then you should use a DataReader, since it excels in this scenario.

On the other hand, if you want more complex functionality as far as searching for records or picking out specific records based on an index, then you should really be using a DataSet.

Right tool for the job, as they say.
 
Ok, I'll bear that in mind. In my desktop apps I have a Media Player 11-type search function where in all list views there is a search box which filters the list as soon as a key is pressed. Works very well with even thousands of records, because it's mostly processing power at the client end because of the DataSet feature. Will have to consider workarounds for that.

What about the program as a whole? If I have a Windows Form with a DataGridView listing hundreds of records at a time, is this going to be much slower than the ASP.NET equivalent when pulling data over the web? If anyone here has used Microsoft Money, it looks almost exactly what I'm after, with an application-based interface but webpage-like pages when navigating within the program:
money06.jpg


What language or combination of languages would be used to achieve this?
 
I would use web services with asynchronous calls. You can maintain the client/server design, but still have a very rich client side GUI not restricted by crappy HTML and CSS. I'd personally avoid using DataSets too and adopt service-oriented architecture (SOA). Web services + SOA is just so powerful and once you've tried it you won't ever go back :)

Web services aren't the fastest thing in the world (XML overheads) but it doesn't really matter as long as you can come up with good ways to present the GUI. Use virtualised ListView's, caches, asynchronous calls. You can really make your application something special this way, rather than just being "yet another .NET database app' using the bog standard controls".

If you're needing to display thousands of rows of data then something is wrong with your design. Either fundamentally or just with the GUI. Offer search facilities to the user. And only ever download records from the server that actually need to be displayed. Never download all the records assuming the user will view them all.
 
Last edited:
NathanE said:
I would use web services with asynchronous calls. You can maintain the client/server design, but still have a very rich client side GUI not restricted by crappy HTML and CSS. I'd personally avoid using DataSets too and adopt service-oriented architecture (SOA). Web services + SOA is just so powerful and once you've tried it you won't ever go back :)

Web services aren't the fastest thing in the world (XML overheads) but it doesn't really matter as long as you can come up with good ways to present the GUI. Use virtualised ListView's, caches, asynchronous calls. You can really make your application something special this way, rather than just being "yet another .NET database app' using the bog standard controls".

If you're needing to display thousands of rows of data then something is wrong with your design. Either fundamentally or just with the GUI. Offer search facilities to the user. And only ever download records from the server that actually need to be displayed. Never download all the records assuming the user will view them all.
Click to expand...

Good post :) Will take note of your last paragraph, it's for a recruitment agency so I guess the default view for say 'Applicants' could be only those who aren't currently employed, with other tabs to show 'employed' and 'all' (the latter I am assuming won't be used much).

I'm going off to do a good bit of reading on this now, but could you still throw some ideas my way relating to "virtualised ListView's, caches, asynchronous calls"? I am being shouted at to get this application up & running quickly and I want to get up to speed with these new ideas.
 
A lot of it is explained here http://blogs.msdn.com/cumgranosalis/archive/2006/03/06/VirtualListViewUsage.aspx

Web services in .NET provide asynchronous methods that you can call. The idea is that you "make the call" and then once you've got the response back it raises an event - at which point you can handle the response. The design pattern is normally something like, e.g.:

void SomeMethod() {
ws_proxy.GetApplicantById += // subscribe event code
GetApplicantByIdAsync(their_id);
}

void GetApplicantByIdCompleted(...) {
// Applicant object is stored in e.Result
}
 
NathanE said:
A lot of it is explained here http://blogs.msdn.com/cumgranosalis/archive/2006/03/06/VirtualListViewUsage.aspx

Web services in .NET provide asynchronous methods that you can call. The idea is that you "make the call" and then once you've got the response back it raises an event - at which point you can handle the response. The design pattern is normally something like, e.g.:

void SomeMethod() {
ws_proxy.GetApplicantById += // subscribe event code
GetApplicantByIdAsync(their_id);
}

void GetApplicantByIdCompleted(...) {
// Applicant object is stored in e.Result
}
Click to expand...
Why not use the standard .NET approach to asynchronous method calls? For example:
Code: 
void SomeMethod()
{
    wsProxy.BeginGetApplicantById(id, OnGetApplicantByIdCompleted, null);
}

void OnGetApplicantByIdCompleted(IAsyncResult result)
{
    Applicant applicant = wsProxy.EndGetApplicantById(result);
}

I've never used web services before though, so admittedly I don't know much about them.
 
Actually I just tested an application I built about a year ago, installed SQL Express at the server I will be running the new program from, and ran the app from here over a VPN and it runs verrrry impressive indeed :) :) That program was not efficient at all in its Fill() commands, simply selecting every field in every row in the database and firing it down, including note/memo fields etc. To pull down a table of 500 records with ~15 columns took about 2 seconds. The code I will be implementing now will be so much more optimised so I can improve that to no end. Not quick, but that's without web services or anything.

So now I know I can give at least satisfactory performance with my solution to start off with, but I'm still wanting to take it a step further. The asynchronous calls interest me since there isn't a lot of modification required to existing code. I found a good article on CodeProject here . The following is code from a previous project where a few Fill() commands are called to populate a DataGridView and a few search dropdowns. On a slower connection, the form does not display until each of the Fill() commands have been completed. How would I modify even one of these commands to run it on an asynchronous thread?

Code: 
private void formMachineList_Load(object sender, EventArgs e)
{
this.manufacturerTableAdapter.FillManufacturerList(this.myDataSet.Manufacturer);
this.machineCategoryTableAdapter.Fill(this.myDataSet.MachineCategory);
this.customerTableAdapter.FillCustomerList(this.myDataSet.Customer);
}
 
Inquisitor said:
Why not use the standard .NET approach to asynchronous method calls? For example:
Code: 
void SomeMethod()
{
    wsProxy.BeginGetApplicantById(id, OnGetApplicantByIdCompleted, null);
}

void OnGetApplicantByIdCompleted(IAsyncResult result)
{
    Applicant applicant = wsProxy.EndGetApplicantById(result);
}

I've never used web services before though, so admittedly I don't know much about them.
Click to expand...
That's the old way which require more code and doesn't use .NET events :) Also an *Async call will always raise the event delegate on the same thread that the proxy was created - so you don't have any synchonisation headaches.

PS: I'm talking strictly about web services here. You can perform asynchronous calls on most things in .NET and using them is always a good thing.
 
I'm curious about the whole Dataset/Datareader/Web thing.

You will never send a dataset to a web client (unless they are consuming a web service, but that's another fish-kettle).

You'll use the dataset to populate a datgrid/repeater/list/whatever, which will render some html and send the html to the webn client. It doesn't matter if you hand-write the entire table, or generate it from cream-cheese...it'll still be the same html and therefore exactly the same bandwidth.

Confused!

:)
 
You must log in or register to reply here.
Back
Top Bottom