application.
In question is the choice of client application:
I need to be able to speak intelligently about when one client (MS Access vs
.NET Windows Forms) would be preferred over the other. While I have some
good arguments on both sides, I would appreciate your points of view on the
topic.
For the sake of this discussion, please assume a *non trivial* client
application with, say 120 forms, secure data processing, hundreds of
reports, and a clear need for a rich UI experience (MDI, a variety of rich
UI controls, non trivial printing requirements, etc).
I would appreciate help in compiling arguments both for and against each
technology (MS Access and .NET Windows Forms) as a client application.
So far I have this (in no particular order):
BENEFITS OF a .NET Windows Forms Application:
1. Client can be MDI (whereas Access only SDI)
2. Much richer UI with .NET (vs MS Access UI controls)
3. Easier deployment (with ClickOnce, XCopy, and similar .NET technologies
or methods). The client already has the CLR installed as part of their
standard desktop image - so I need to put nothing more than "XCopy" the
application files onto the local machine.
4. .NET requires a smaller footprint on the client with respect to the use
of 3rd party UI controls. MS Access is a COM-based technology and therefore
requires that 3rd party controls be COM controls. These require installation
to Windows\System32 and associated updates to the Registry (whereas .NET 3rd
party controls require only XCopy deployment to the application folder)
5. 3rd party UI controls for .NET are more prevalent, capable, and rich than
3rd party COM controls. Plus support for COM controls (i.e. number of 3rd
party companies making and supporting them) is expected to only decrease,
not increase, during the coming years - with the exact opposite trend
expected for 3rd party .NET controls.
6. .NET Windows Forms applications can take full advantage of OOP constructs
and patterns - thereby enabling the developers to create applications that
are easier to maintain, more easily extensible, and better architected than
the "equivalent" functionality provided in an MS Access application.
7. Visual Studio .NET significantly increases developer productivity (vs MS
Access support for application development)
8. The .NET base classes significantly increase developer productivity by
pre-packing substantial functionality that would have to be coded from
scratch in MS Access.
9. Runtime performance of a .NET application would likely be faster than MS
Access because MS Access (really Jet) necessarily entails a file server
architecture, while ADO.NET necessarily entails a distributed (and
disconnected) architecture.
10. ADO.NET takes care of connection pooling automatically and provides a
huge amount of built-in functionality that substantially increases developer
productivity and increases programmer control over database communications
and updates (as compared to JET and DAO).
DOWNSIDE OF a .NET Windows Forms Application:
1. Increased expertise required for .NET development - vs. MS Access (at
least that's the perception of the client)
2. Requires the target version of the CLR to be installed on the client
machines (leading possibly to multiple versions of the .NET Framework
installed simultaneously. Not that I have a problem with it, but their
desktop support folks might).
BENEFITS OF a .MS Access Client Application:
1. Less expertise required on the part of the developers (at least that's
the perception of the client).
2. Out of the box it includes many useful UI controls and a first-class
report writer.
DOWNSIDE OF a .MS Access Client Application:
1. Insert right here THE EXACT OPPOSITE of all of the benefits of a .NET
Windows Forms application, then:
2. The client machine must have the correct version of MS Access installed
(i.e. they're stuck with a particular version, or all must upgrade
simultaneously).
3. Passthrough queries would be required in order to get the query
processing to happen on the server. Passthrough queries ential some
additional complexity than non passthrough queries.
4. Without the use of passthrough queries, SQL Server's locking mechanisms
can behave unexpectedly (e.g., locks can unexpectedly be placed on tables
rather than pages or rows) - thereby resulting in slower performance.
5. Date processing logic is less secure because users can, relatively
easily, view and modify the client-side code and/or queries.
Any additions to these lists are greatly appreciated!
JordanThat's amusing. I won't attempt to correct your opinions,
but note that you haven't addressed reporting yet. I've
used Crystal, Access, and Report Services, and my opinion
is that you really need to accommodate the skill set of your
developers.
(david)
"Jordan S." <A@.B.COM> wrote in message
news:%23iVVsYoXGHA.196@.TK2MSFTNGP04.phx.gbl...
> SQL Server will be used as the back-end database to a non trivial client
> application.
> In question is the choice of client application:
> I need to be able to speak intelligently about when one client (MS Access
> vs .NET Windows Forms) would be preferred over the other. While I have
> some good arguments on both sides, I would appreciate your points of view
> on the topic.
> For the sake of this discussion, please assume a *non trivial* client
> application with, say 120 forms, secure data processing, hundreds of
> reports, and a clear need for a rich UI experience (MDI, a variety of rich
> UI controls, non trivial printing requirements, etc).
> I would appreciate help in compiling arguments both for and against each
> technology (MS Access and .NET Windows Forms) as a client application.
> So far I have this (in no particular order):
> BENEFITS OF a .NET Windows Forms Application:
> 1. Client can be MDI (whereas Access only SDI)
> 2. Much richer UI with .NET (vs MS Access UI controls)
> 3. Easier deployment (with ClickOnce, XCopy, and similar .NET technologies
> or methods). The client already has the CLR installed as part of their
> standard desktop image - so I need to put nothing more than "XCopy" the
> application files onto the local machine.
> 4. .NET requires a smaller footprint on the client with respect to the use
> of 3rd party UI controls. MS Access is a COM-based technology and
> therefore requires that 3rd party controls be COM controls. These require
> installation to Windows\System32 and associated updates to the Registry
> (whereas .NET 3rd party controls require only XCopy deployment to the
> application folder)
> 5. 3rd party UI controls for .NET are more prevalent, capable, and rich
> than 3rd party COM controls. Plus support for COM controls (i.e. number of
> 3rd party companies making and supporting them) is expected to only
> decrease, not increase, during the coming years - with the exact opposite
> trend expected for 3rd party .NET controls.
> 6. .NET Windows Forms applications can take full advantage of OOP
> constructs and patterns - thereby enabling the developers to create
> applications that are easier to maintain, more easily extensible, and
> better architected than the "equivalent" functionality provided in an MS
> Access application.
> 7. Visual Studio .NET significantly increases developer productivity (vs
> MS Access support for application development)
> 8. The .NET base classes significantly increase developer productivity by
> pre-packing substantial functionality that would have to be coded from
> scratch in MS Access.
> 9. Runtime performance of a .NET application would likely be faster than
> MS Access because MS Access (really Jet) necessarily entails a file server
> architecture, while ADO.NET necessarily entails a distributed (and
> disconnected) architecture.
> 10. ADO.NET takes care of connection pooling automatically and provides a
> huge amount of built-in functionality that substantially increases
> developer productivity and increases programmer control over database
> communications and updates (as compared to JET and DAO).
> DOWNSIDE OF a .NET Windows Forms Application:
> 1. Increased expertise required for .NET development - vs. MS Access (at
> least that's the perception of the client)
> 2. Requires the target version of the CLR to be installed on the client
> machines (leading possibly to multiple versions of the .NET Framework
> installed simultaneously. Not that I have a problem with it, but their
> desktop support folks might).
> BENEFITS OF a .MS Access Client Application:
> 1. Less expertise required on the part of the developers (at least that's
> the perception of the client).
> 2. Out of the box it includes many useful UI controls and a first-class
> report writer.
> DOWNSIDE OF a .MS Access Client Application:
> 1. Insert right here THE EXACT OPPOSITE of all of the benefits of a .NET
> Windows Forms application, then:
> 2. The client machine must have the correct version of MS Access installed
> (i.e. they're stuck with a particular version, or all must upgrade
> simultaneously).
> 3. Passthrough queries would be required in order to get the query
> processing to happen on the server. Passthrough queries ential some
> additional complexity than non passthrough queries.
> 4. Without the use of passthrough queries, SQL Server's locking mechanisms
> can behave unexpectedly (e.g., locks can unexpectedly be placed on tables
> rather than pages or rows) - thereby resulting in slower performance.
> 5. Date processing logic is less secure because users can, relatively
> easily, view and modify the client-side code and/or queries.
> Any additions to these lists are greatly appreciated!
> Jordan
>|||Thanks for your perspective. Skill set of the developers is very important
as you mentioned, and a shorter learning curve on Access may be relevant to
the final decision.
Please feel free to add to the lists - *all* sides must be represented.|||Why do you say that Access is only SDI? You can open multiple forms,
each one individually resizable & repositionable within the Access
application window. Sounds like MDI, to me!
One of the primary advantages of Access, IMO, is its data-bound
controls. You don't need any code at all, to bind a control to a field
in the data source of a form or report.
As for the rest, IMHO you are asking too much from a newsgroup staffed
by volunteers. It would be a non-trivial consulting task to provide the
detailed comparative report that you want. And you'd really want it to
be done by someone who was expert in both technologies (winforms and
Access). Otherwise, it's too easy for the winforms person to slag
Access (through lack of knowledge of the product), and vice versa.
HTH,
TC (MVP Access)
http://tc2.atspace.com|||It just frightens me that anyone would even consider using MS Access as
anything other than a torture device. Your point #6 for .NET benefits
is very important, and could easily be split out into about 20.
When the application needs to change to do some extra functionality
like access a web service, or perform complex operations on your data
then you would start crying if you were using access. An application
with 120 forms is probably going to have some seriously complex
requirement changes coming out that you won't find out about until mid
way through developing it (usually when the client actually sees a
screen working then says "oh, but if it's a saturday and it's raining
we don't do it like that"). You'll need the ability to put in some
serious design patterns that permit you to change this without having
to re-structure everything.|||Nonsense. A well designed & written systems can generally be enhanced
without much trouble. A badly designed & written system can't. The
workman has much more effect on this, than the tool. You could easily
have a well designed & written Access system, that was easy to enhance,
and a badly designed & written .NET system, that was a nightmare to
enhance.
TC (MVP Access)
http://tc2.atspace.com|||"Jordan S." <A@.B.COM> wrote in message
news:%23iVVsYoXGHA.196@.TK2MSFTNGP04.phx.gbl...
> 2. Much richer UI with .NET (vs MS Access UI controls)
While it is true that there is a wider range of controls available in .NET,
Access provides all the controls that a typical data-centric application
really needs.
> 4. .NET requires a smaller footprint on the client with respect to the use
> of 3rd party UI controls. MS Access is a COM-based technology and
> therefore requires that 3rd party controls be COM controls. These require
> installation to Windows\System32 and associated updates to the Registry
> (whereas .NET 3rd party controls require only XCopy deployment to the
> application folder)
See my answer to point 2 above. The availability or otherwise of third-party
controls isn't an issue when you don't need any third-party controls.
> 5. 3rd party UI controls for .NET are more prevalent, capable, and rich
> than 3rd party COM controls. Plus support for COM controls (i.e. number of
> 3rd party companies making and supporting them) is expected to only
> decrease, not increase, during the coming years - with the exact opposite
> trend expected for 3rd party .NET controls.
See answers to 2 and 4 above.
> 7. Visual Studio .NET significantly increases developer productivity (vs
> MS Access support for application development)
This has not been my experience.
> 8. The .NET base classes significantly increase developer productivity by
> pre-packing substantial functionality that would have to be coded from
> scratch in MS Access.
This has not been my experience.
> 9. Runtime performance of a .NET application would likely be faster than
> MS Access because MS Access (really Jet) necessarily entails a file server
> architecture, while ADO.NET necessarily entails a distributed (and
> disconnected) architecture.
I can't say for sure whether a .NET app is likely to be faster, but I can
say from experience that a well-designed Access app can perform more than
satisfactorily on a LAN.
> 10. ADO.NET takes care of connection pooling automatically and provides a
> huge amount of built-in functionality that substantially increases
> developer productivity and increases programmer control over database
> communications and updates (as compared to JET and DAO).
See answers to 7 and 8 above regarding developer productivity.
> 2. The client machine must have the correct version of MS Access installed
> (i.e. they're stuck with a particular version, or all must upgrade
> simultaneously).
Not necesarily. Access 2002 and 2003 use the same file format by default as
Access 2000. You can run the same MDB under the last three versions of
Access, provided you are careful not to use any new features that were not
supported in Access 2000.
> Any additions to these lists are greatly appreciated!
You haven't mentioned what you're going to use for reporting in .NET. SQL
Server Reporting Services is
in many respects, but I miss the tightintegration of the Access report designer and engine, and SQL Server
Reporting Services requires additional installation and configuration on the
server.
Generally speaking, my experience so far is that ASP.NET has been a great
leap forward for Web-based applications, but I remain to be convinced about
the benefits of using Windows Forms for typical data-centric desktop
applications.
Brendan Reynolds
Access MVP|||Fair point that the developer skill is the key factor.
But do you really see Access as a scalable solution for a 120 form
application? I do admit that I've only had a few frustrating encounters
with access forms applications, however it seemed to me that while
their databound controls are their strength for a simple application,
they lack the expressiveness available to .NET controls. I can see the
advantage of access forms if it's managing the database as well, but
when you need to have very particular formatting of your controls, and
tie in to a large variety of events .NET is definitely easier / more
obvious in how to do this.
Secondly, while I do accept that a .NET application can be written
badly, if written well then it will provide a more scalable and
maintainable architecture. I don't believe that Access was designed to
develop complicated middle tier logic, and while it may be possible to
do it in Access, .NET was built with this in mind.
I do agree we shouldn't start bashing other technologies though, so
please ignore my "torture device" comment posted previously|||Will wrote:
> Fair point that the developer skill is the key factor.
> But do you really see Access as a scalable solution for a 120 form application?[/c
olor]
Access can easily handle 120 forms. There'd be squintillions of working
Access databases around the world with that number. However, you're
certainly right, that the number can not grow arbitrarily. So, winforms
might be more scalable here - I don't know.
But it does raise the question, how many is enough? What are all these
forms *for*, in systems that have hundreds & hundreds & hundreds of
forms? Every time I hear of one, I think: "Geez, surely it would be
possible to have a smaller # of forms & let them customize themselves
at runtime".
> I do admit that I've only had a few frustrating encounters
> with access forms applications, however it seemed to me that while
> their databound controls are their strength for a simple application,
> they lack the expressiveness available to .NET controls. I can see the
> advantage of access forms if it's managing the database as well, but
> when you need to have very particular formatting of your controls, and
> tie in to a large variety of events .NET is definitely easier / more
> obvious in how to do this.
It's hard to comment without specifics. You may be right - I don't know
enough about winforms to have an opinion. Certainly the Access event
model has a few deficiencies.
> Secondly, while I do accept that a .NET application can be written
> badly, if written well then it will provide a more scalable and
> maintainable architecture. I don't believe that Access was designed to
> develop complicated middle tier logic, and while it may be possible to
> do it in Access, .NET was built with this in mind.
You may well be right. I don't know enough about .NET & winforms to
have an opinion yet.
> I do agree we shouldn't start bashing other technologies though, so
> please ignore my "torture device" comment posted previously
No probs, thanks for that acknowledgement. I was girding my loins, to
enter the fray!
Cheers,
TC (MVP Access)
http://tc2.atspace.com|||Thanks for your perspective TC.
A couple of thoughts:
RE:
<< It would be a non-trivial consulting task to provide the detailed
comparative report that you want.>>
Exactly! That's my job and that's why I provided the initial lists in the OP
(to get the ball rolling). I hope I provided at least the "big hits" and
that that good folks here in the NG can just scan and say "oh, you missed x,
y, or z".
RE:
<< And you'd really want it to be done by someone who was expert in both
technologies (winforms and Access). >>
That's me to some extent also. FWIW I have 5 years of full-time and non
trivial MS Access programming experience (Access 2.0 through 97), 4 years in
VB, and 3 in .NET. So I can lay claim to some awareness of the strengths of
MS Access, plus some other technologies.
RE:
<< Otherwise, it's too easy for the winforms person to slag Access... and
vice versa >>
I'm not here to bash MS Access nor start any flame war. I'm just recognizing
a situation where it may not be the *best* tool for the job. Rather than
just saying "geeze we shouldn't use Access for non trivial UI programming" I
want to be able to state specifically why. And if I'm wrong in my
assumptions or beliefs then I also want to know specifically why.
Finally, towards avoiding a flame war, I'd like to encourage respondents to
avoid arguing against any points anyone here makes. All are taken as either
[completely valid] or [perceived as valid] and thus are greatly appreciated.
Thanks again!
