smucRJG
asked on
WCF 4 and winforms (using ado.net)
For the second time in a couple of years I find myself having to navigate between old and new technologies.
I want to develop what amounts to a basic Enterprise Service Bus (ESB) using WCF (4) that will enable the organisation I work for to consume and generate web services, run distributed applications (data access and business process), connect various backend SQL Servers and run various web and windows based user interfaces. This is in the longer term.
In the short term (a couple months at the most) I need to deliver on Line of Business UIs that are data intensive and quite heavy duty in terms of data volume and complexity. For this I want to use ADO.NET (not the new WCF version) and Winforms (actually, Infragistics winform components) because I am familiar with these and I don't have time to familiarise myself with more up to date options (such as WPF, Silverlink, WCF data services, etc.), although I am intending to do this in the medium term.
My questions, which are really quite high level, are:
A) Will I be able to set up the necessary data access and business layers and UIs based on (old) ADO.NET using WCF 4 to manage communications.
B) Windows based applications seem to be loosing favour with microsoft very rapidly, but from my experience they seem to provide a better user experience for down to earth data entry, data display (grids, etc.) and process management than any web based screen I have seen (better speed performance, less jumping around and loosing position on screen, better refreshing, less on-screen clutter, etc.). - can I ever hope to achieve Windows quality with a more up to date WEb based application (or WPF controls)?
Thank you for your asdvice and opinions in advance.
I want to develop what amounts to a basic Enterprise Service Bus (ESB) using WCF (4) that will enable the organisation I work for to consume and generate web services, run distributed applications (data access and business process), connect various backend SQL Servers and run various web and windows based user interfaces. This is in the longer term.
In the short term (a couple months at the most) I need to deliver on Line of Business UIs that are data intensive and quite heavy duty in terms of data volume and complexity. For this I want to use ADO.NET (not the new WCF version) and Winforms (actually, Infragistics winform components) because I am familiar with these and I don't have time to familiarise myself with more up to date options (such as WPF, Silverlink, WCF data services, etc.), although I am intending to do this in the medium term.
My questions, which are really quite high level, are:
A) Will I be able to set up the necessary data access and business layers and UIs based on (old) ADO.NET using WCF 4 to manage communications.
B) Windows based applications seem to be loosing favour with microsoft very rapidly, but from my experience they seem to provide a better user experience for down to earth data entry, data display (grids, etc.) and process management than any web based screen I have seen (better speed performance, less jumping around and loosing position on screen, better refreshing, less on-screen clutter, etc.). - can I ever hope to achieve Windows quality with a more up to date WEb based application (or WPF controls)?
Thank you for your asdvice and opinions in advance.
ASKER
Thank you for your comments. I totally understand the argument you make with respect to maintenance, etc..
If I would like to ask a couple of other questions of you or any other expect:
A) Can you give examples of areas where a Web App cannot touch a desktop application (in my original question, for the sake of brevity I did not go into any detail as to what the desk top applications I need would be expected to do).
B) This may seem prehistoric in concept, but I was considering the possibility of passing generic data sets as objects through the data access layer (via WCF?) to the UI, which would be configurable on the fly according to parameter driven instructions also sent to the UI, for consumption by Infragistics components. This would all be orchestrated by the business application. I have used similar schemes in the past (ADO/COM+ based) and it worked well as it only requires a limited number of data access methods (e.g. extract data set according to stored procedure; transactional update of fields; etc.) and the same form template can often (not always) be reused. Is this possible using WCF (passing data sets as complete objects) and what's the nearest equivalent?
Thanks
If I would like to ask a couple of other questions of you or any other expect:
A) Can you give examples of areas where a Web App cannot touch a desktop application (in my original question, for the sake of brevity I did not go into any detail as to what the desk top applications I need would be expected to do).
B) This may seem prehistoric in concept, but I was considering the possibility of passing generic data sets as objects through the data access layer (via WCF?) to the UI, which would be configurable on the fly according to parameter driven instructions also sent to the UI, for consumption by Infragistics components. This would all be orchestrated by the business application. I have used similar schemes in the past (ADO/COM+ based) and it worked well as it only requires a limited number of data access methods (e.g. extract data set according to stored procedure; transactional update of fields; etc.) and the same form template can often (not always) be reused. Is this possible using WCF (passing data sets as complete objects) and what's the nearest equivalent?
Thanks
a) Things like vector drawing, advanced mathematics, that sort of thing. There is also the issue of local resource access (i.e., saving files, hardware peripherals like image capture devices) that are still clunky to work with in web applications. Since compiled applications outperform JavaScript with things like data sorting, advanced algorithms or modeling (like you would find in an engineering CAD application), those scenarios can be better suited to desktop. I have, however, written JavaScript based UI's that handled thousands of sortable records, and there is always the option of server-side sorting, so the requirements have to be pretty fierce to justify ruling out web apps entirely.
b) While I've never done DataSets via WCF, I don't see any reason why it shouldn't be possible (DataSets are serializable, IIRC). A DataSet comes with a great deal of overhead, however. Even if the data you're dealing with is genuinely generic, something like a collection of dictionaries would be a leaner data transfer option. I guess the exception would be if you actually needed all that overhead - i.e. you were sharing the state of data between layers (since DataSet versions data between updates) and wanted to include relational metadata as well.
In any case, I would be highly suspect of that sort of approach. The system is less self-documenting as a result - both ends of the data conduit need to know what the other end is doing in order for the system to work. With a data contract or WSDL, each component's requirements are clear, and dependencies are explicit.
b) While I've never done DataSets via WCF, I don't see any reason why it shouldn't be possible (DataSets are serializable, IIRC). A DataSet comes with a great deal of overhead, however. Even if the data you're dealing with is genuinely generic, something like a collection of dictionaries would be a leaner data transfer option. I guess the exception would be if you actually needed all that overhead - i.e. you were sharing the state of data between layers (since DataSet versions data between updates) and wanted to include relational metadata as well.
In any case, I would be highly suspect of that sort of approach. The system is less self-documenting as a result - both ends of the data conduit need to know what the other end is doing in order for the system to work. With a data contract or WSDL, each component's requirements are clear, and dependencies are explicit.
ASKER
That's really helpful information. It will help me navigate my way through the next couple of months.
One last question, if I may (this really will be the last):
I have always used VB.net. One of the best books I have found for WCF 4 was a recent Wrox publication. I checked the source code download accompanying the book and all the examples were in C# - they were not in VB as well, as I was expecting. What is the status of VB with respect to WCF 4 - am I going to be limited in any way?
Thanks in anticipation.
One last question, if I may (this really will be the last):
I have always used VB.net. One of the best books I have found for WCF 4 was a recent Wrox publication. I checked the source code download accompanying the book and all the examples were in C# - they were not in VB as well, as I was expecting. What is the status of VB with respect to WCF 4 - am I going to be limited in any way?
Thanks in anticipation.
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
ASKER
That's reassuring.
Thank you for your assistance - great stuff
Thank you for your assistance - great stuff
You'd deliver data to the front end using WCF in an app server cloud or cluster, and use ADO.NET to handle interaction with your database from the app server. This is still a sound approach, IMO.
Windows based applications aren't losing favor altogether, just when it comes to enterprise environments. They simply cost more to deploy and maintain - a centralized web app has so, so many benefits in terms of ease of maintenance, deployment, licensing (when applicable), and security. Especially consider that corporate workstations/laptops see much quicker turnover than server hardware.
A web application can deliver a very comparable experience in terms of UI responsiveness, provided your application server layer has the bandwidth and resources to provide it. My consulting firm has replaced countless data entry apps that were developed in, for instance, Delphi with web applications that provide the same efficiency to the end user - keyboard shortcuts, non-refresh interface, etc. etc., without all of the problems (how many desktop applications were broken by x64, CAS, and UAC?)
There are undoubtedly areas where a web app cannot touch a desktop application, but the assumption that your UX will suffer for something simple like data entry isn't necessarily a sound one.