Kevin,

You're right and they're wrong. <g> Seriously, we have our app structured exactly the same way as you do. All access to data on the client-side is through a WebService that accesses server-side components. If you need to have quick frequent access to a particular DataSet for frequently used picklists or combo boxes, you could cache the DataSet as XML on the client-side. We do that too. It works great.

Don't let anyone talk you into doing it the "wrong" way.

~~Bonnie



>Hi, all...
>
>Someone recently made a suggestion to me, and I wanted to find out what everyone thought...
>
>We have a .NET app with WinForms and Crystal Reports on the local client machine, a Web Service that receives requests from the local end to run specific functions, a large middle-tier structure, a data access component, and SQL Server.
>
>Our UI is quite rich, and we bring down ADO.NET datasets from the middle-tier, to satisfy user requirements for being able to scroll through lists, run reports frequently, etc.
>
>The suggestion made was to keep data retrieved from SQL Server in the middle tier, and have things like grids, pick-lists, reports, etc. 'read' the data directly from the middle-tier. That way, no ADO.NET data would need to be 'downloaded' to the client's machine.
>
>This seems, at least to me, to be impractical, as every mouse click, grid scroll navigation, etc. would potentially require a call back to the middle-tier (which is sitting behind a web service). Whatever time you might save by eliminating the initial download of data would be lost during normal user navigation. It also seems to me that this approach would increase the chance for data loss, if a user is editing a row that is actually residing in the middle-tier...if the connection to the server is lost, I suppose the changes someone makes would be lost as well.
>
>Thoughts?
>Thanks,
>Kevin