Re: convincing a client to go with dotNet instead of Access projec
- From: "John DeBoer" <JohnDeBoer@xxxxxxxxxxxxxxxxxxxxxxxxx>
- Date: Thu, 28 Apr 2005 13:17:40 -0700
I've had this fight, too, and initially lost but won in the long run. The
Access project works for shorter term projects that can tolerate a certain
amount of sloppiness. Granted, it is hard to give an example of something
that cannot be done in Access but the .NET infrastructure lends itself to a
much more polished, secure, controlled and scalable solution. The .NET
solution lends itself to a well organized, object oriented, solution while
Acess projects often grow into a spegetti type mess.
The problem is that your counterpart is right about how quickly things can
be developed in Access. In the short run you'll get further, faster, with
Access. However, once you get the .NET environment setup it is very quick
and easy to reuse existing logic to create additional pages. You won't end
up having to re-write the .NET project but you are likely to outgrow the
Access solution.
Your counterpart's argument about Access's nice reporting interface is
correct but you should look into SQL Server's reporting services. It really
offers a nice range of options for output and some nice drill-down options
that you won't find in Access. It is always possible to step into this
transition by keeping a "Reports" project that ties into the same database.
Finally, I'd focus on security because that is something I see as a big
difference, depending on how good you are about protecting data in the Access
projects. Often, users are given select permission on entire tables. This
means that they could create a new project and play all sorts of havoc with
your data. The .NET solution is likely to make better use of stored
procedures and a much more sophisticated security infrastructure.
"Flip" wrote:
> I've had this "fight" before and lost. :< Fortunately for the client the
> apps life was only supposed to be six to twelve months long. Unfortunately
> for the client, we ended up creating a release a week in the last phases of
> development. :<<<< Deployment out to regional office was a NIGHTMARE! We
> didn't have probs with synchronization cause we used Access for the forms
> creation/execution only. We were using Access to access a central SQL
> Server. However, like you mentioned, I believe using something VB in my
> case (or C# in your case today :>) is the better way to go. BUT, possibly
> your biggest hurdle will be the front end is already developed in Access. :<
> That is hard to compete against.
>
> Cons to using C#
> -new paradigm, language, IDE, manager are always afraid of change
> -learning curve for language, APIs, deployment management, etc
> -hey Access is better than using java/swing to do it!
> -hey if the UI is in Acces why change? that's a tough one you probably
> can't argue against, MS afterall isn't going to rewrite MS Office in C# from
> C++ over night
>
> Pros to using C#
> -huge integration with SQL Server
> -MUCH better form design support in VS than in Access (IMHO that is)
> -better multi-user architecture in WinForms than in Access
> -better control over version control, source control, setup programs
> -opportunity to easily document code (UML, documentation from code comments)
> -opportunity to extend the "reach" of the application with giving it a web
> front end later on, maybe webservices, RSS, etc
> -Access really tops out with performance after six concurrent connections
> (does your manager know that?)
> -better support for code/development help with C# than with Access (ok,
> that's a bit of exaggeration, but I'm biased :>)
> -with .NET you can use Crystal Reports, which is MUCH superiour to Access
> for reports (if that is truely a main concern for management)
>
> Having said all this, you might be fighting a losing battle. Good luck to
> you, but you might have better luck with a future project than with this
> one. But that's cool, you're setting the framework with management about
> the pros/cons of .NET. Also be careful when you compare .NET to Access.
> Access is the DB, and also the development and runtime environment. .NET is
> the framework, VB.NET and C# are the languages you code in, and VS2k3 is the
> development environment (which I'm sure you already know that :>). I see
> unfair comparisons with java to .NET, that's like apples and oranges, .NET
> to J2EE is the fair comparison, like C# is to java, or WinForms to Swing.
>
> Good luck with this! :>
>
>
> "bill" <belgie@xxxxxxxxxxx> wrote in message
> news:Oy$i5WCTFHA.3840@xxxxxxxxxxxxxxxxxxxxxxx
> >I am trying to convince a client that dotNet is preferable to an Access
> > project (ADP/ADE).
> >
> > This client currently has a large, pure Access MDB solution with 30+
> > users,
> > which needs to be upgraded.
> >
> > I believe a dotNet solution is better, but I'm trying to be as convincing
> > as
> > possible -- and maybe I'm wrong!
> >
> > I would appreciate any input or references which could help me.
> >
> > My reasons for going with a dotNet solution are:
> > - The multi-tier environment is more desirable because it is easier to
> > deploy updates, such as a centralized web service, or as web forms
> > - The ADP is less efficient because it requires a continuous connection
> > to the backend database, whereas ADO.NET is disconnected
> > - I can use object oriented techniques, such as inheritance
> > - A dotNet solution requires less bandwidth (some users will be
> > accessing
> > the database over a VPN pipe)
> > - Code can be re-used more easily
> >
> > The ADP promoter cites the following arguments:
> >
> > - Access has better reporting capabilities
> > - Access is quicker to develop in
> > - The ADP is just as efficient as a dotNet solution in terms of data
> > access
> > - The front end is already built in Access
> >
> > Thanks!
> > Bill
> >
> >
>
>
>
.
- References:
- Prev by Date: Re: convincing a client to go with dotNet instead of Access project
- Next by Date: Re: How to store my .NET project on a server?
- Previous by thread: Re: convincing a client to go with dotNet instead of Access project
- Next by thread: Re: convincing a client to go with dotNet instead of Access project
- Index(es):
Relevant Pages
|
Loading