Application architecture advice needed

[DevoRevolution]

My group is taking over a large number (about 40) of old Access 97
databases within a large healthcare organization, and will eventually
rewrite them all using .NET and SQL Server. However, our developers
have limited experience in .NET and we are trying to determine the
best technological solutions that will allow us to reuse code and
rewrite most of these applications with common architecture for faster
development and easier maintenance.

The primary question we are dealing with is whether to use a compiled
executable (VB.NET) or web architecture (ASP.NET and javascript with
server components in VB.NET), or some other architecture or variant.
Another option is to create a common set of middle tier utilities (if
that is possible) and decide for each application whether the GUI is
better developed as a .exe or web app. Our company is primarily a
Microsoft shop, so please hold the MS vs the World Flame War - as
valid as that issue may be, it doesn't help us out.

Given recent advances in web application technologies (Ajax, etc), it
appears that most normal application requirements (security, interface
elements, responsiveness, etc.) can be met in either paradigm, though
it appears that in web development, additional work is required to
accomplish things that are automatic or simpler in a .exe. However,
executables can be problematic for installation and upgrades on locked-
down windows images, and may have network security access issues as
well. In addition, there seems to be a general perception by users
and managers that web applications are somehow better than
traditional .exe's.

The biggest question for us with this decision is development cycle
time and maintainability - how does going from a VB.NET compiled
application to an ASP.NET application affect those aspects of
development? Are there any useful articles we could read about
programs developed in both and comparisons between them?


The second issue is that we are hoping to find a widely used framework
of some sort that would assist with or perform many of the functions
we will need in all of these applications, such as data access and
management (and do we use XML, LINQ, or ADO?), data validation, edit
logs, data and application security, user account management,
reporting, messaging, documentation, error handling and reporting, and
external interfaces. Ideally we would like to write (and maintain) as
little code as possible. If we can't find anything suitable, we will
probably try to write one ourselves.

We own a dedicated web server that currently has .NET 2.0 on it, but
we can upgrade to 3.5 if needed, and a SQL Server 2000 dedicated
server. Our users are all on Windows 2000 or XP, but we need to plan
for future Vista use as well.

Thanks in advance for any advice

[Andrew Badera]

1. ASP.NET IS compiled. It's not a script like VBScript & classic ASP.
2. Sounds like you guys need a lot of help. Perhaps you should consider hiring an experienced and talented outside resource. Because those of us qualified to answer your questions probably don't have time to go into this conversation at length, without getting paid. I for one am senior software engineer (.NET) for a large managed care organization myself, as well as an incorporated consultant. Feel free to contact me via the info in my sig if you feel like taking this off-list.
3. Why are you worried about anti-MS flame wars? This IS a dotnetdevelopment group ...

--
--Andy Badera
http://higherefficiency.net
http://flipbitsnotburgers.blogspot.com/
http://andrew.badera.us/
http://changeroundup.com/
and...@badera.us
(518) 641-1280
Google me: http://www.google.com/search?q=andrew+badera

[DevoRevolution]

The point of my first question was to discuss the relative merits of a
web interface vs. a traditional .exe within a high security
environment, and hopefully to get some good, impartial reference
sources I can read that discuss the relative pros and cons of the two,
especially with regards to development speed and maintainability, as
well as functionality. I am quite aware that ASP.NET is compiled into
CIL.

I have been programming since the 80's in many languages and
databases, mostly smaller-scale projects, but I have been a technical
lead and designed quite a few databases. However, I have never
designed an n-tier system before (though I have worked on components
of such systems), and have relatively little experience with .NET.
That is why I posted my question here, in addition to reading a number
of books and researching on line, hoping that someone would actually
give me useful information rather than just flaming me for my
perceived lack of experience.

In particular, since we have so many applications to rewrite,
designing them all with a common architecture and set of components
seems obvious, whether it be something I write or (preferrably)
purchase. I also wanted to make their design as flexible as possible
to make sure they can be changed easily as business needs change,
unlike their current versions.

However, every attempt I have made to find such a suite externally
hits the google megahit wall, so I figured asking experts to recommend
something would be a lot easier than trying to spend months trying to
determine which recommendations are paid advertisements, which are
from people who have no clue, and which would actually be useful.
Even recommendations for good application architecture forums to visit
would be helpful, since there are literally thousands of them out
there. Since our budget is limited, I don't want to recommend that we
buy something unless I'm very sure it will be helpful to our effort.

[Andrew Badera]

Flame you? I certainly didn't flame you. But you think what I've said is flaming, allow me to loan you a clue: pack up your granny panties, Nancy, and send the husband over, 'cuz the grill's just gettin' warmed up.

You're in a situation not at all different from hundreds or thousands, or hundreds of thousands, of other developers. If you think your situation is somehow special, make that clear, otherwise, suck up the facts: you're here looking for a lot of information in order to do your job. There's no easy, simple, stock answer. It would take a lot of time to even begin to educate you on the broad range of issues you're facing.

You're here for a quick, easy answer, rather than investing your own time seeking out these answers, learning where to find the individual elements that compose the answers, figuring out the answers through personal experience. Quick, easy answers are commonly available in the marketplace in the form of "consultants." I'm sure you could happily pay various consultants who frequent this list to educate you.

Short of that, you're asking other people to invest time that you are showing yourself as unwilling to invest. How is that fair?

--

[Crisatunity (blog.crisatunity.com)]

My take on your situation is this: You are architecting with new
technologies without enough experience to do so competently. That
doesn't mean you shouldn't try; it means you should understand that
you are bound to try and fail many times before you get it right with
what are obviously new technologies and approaches in your world.
Architecting and implementing require different levels of experience,
much more so for the former.

Two pieces of advice to help you get more from this forum (or any
forum for that matter):

First, get your questions out of the theoretical clouds and give the
group concrete starting points to work with. As fun as theoretical
discussions are, I don't think they are what you need nor what this
group excels at. For instance, your original post in this thread
amounts to a quest for silver bullets which is going to go nowhere
useful for you.

Second, discontinue setting up your posting with "this is what kind of
advice I will accept". Post intelligent and succinct questions and
graciously accept whatever advice you get.

And if you think this post is "flaming" you, then you're too fragile
for this group to help you.

[DevoRevolution]

You do have a point, my question was relatively broad and vague,
partly because I didn't want to bias the responses in any particular
direction. Perhaps also I was a bit too quick to throw out the "f"
word, my apologies.

I do not expect you to write my application for me, and I have been
performing a great deal of research, as well as consulting with
professionals within my organization and within my circle of friends.
I would comment that asking for general suggestions about topics to
research, reference sources or commercial products that might help me
meet my needs is a far cry from doing my job for me, and I probably
should have presented my original question to more clearly request
specifically that information. Incidentally, I have worked for 3
Fortune 500 companies for a total of about 10 years, just not
doing .NET and n-tier architecture design.

I think at this time we're leaning mostly towards a 4-tier solution
using Javascript, ASP.NET, VB.NET and SQL Server. Most of the
applications we would be converting are relatively small Access 97
databases, with data in either Access 97 or SQL Server back ends, many
of which have import and export interfaces primarily using flat files,
FTP and DTS. The primary goal of my entire project is to make sure
that our future architecture framework is consistent and easily
maintainable across all applications, and I'm trying to do as much
legwork as possible before we start coding to ensure that.

To give you more details as to what we are working on, we want to try
to incorporate as many of the following concepts as we can into the
overall framework we use (this is the condensed version):

1. Common code to handle logins, password changes, lockouts, auditing
all login/logout activity, account creation, activation, deletion, and
modification (and auditing thereof).

2. Common code for auditing all edits on all fields on all databases
- possibly using XML diffgrams. Ideally this would be automatically
built into the data access layer so that no additional code would need
to be written except in unusual cases. This would also lend itself to
having automatic history reports showing edit history at different
levels (field, record, parent record) which could be shared across
applications.

3. Common rules and methodology for handling interfaces with external
programs - want to move away from DTS which is the tool we've used in
the past.

4. Common reporting interface with tools designed so that custom ad-
hoc reporting can be more easily created for each application, as well
as the ability for users to store and retrieve their own personal ad-
hoc reports or publish them (given sufficient authority) so that other
users can access.

5. User communication tool both within the application and via email
so that programs can generate messages as needed and convey responses
back to the sender

6. Relatively robust data dictionary so that data validation and
calculation formulae can be stored and their changes tracked over
time. The idea would be to have the data access layer contain classes
that understand how to use the data dictionary, so that the business
layer could inherit the metadata for each of their data elements
without having to individually code them for all fields in all
databases. In addition, the dictionary would define security levels
for individual fields, so that SSN's for example would be hidden by
default unless the user specifically requests to view them, and each
viewing would be logged automatically in all applications. Ideally
this could be programmed to automatically configure custom web
controls to handle validation (I was looking at PeterBlum's suite as
one option).

7. Common interface and practices for help within the application
(tooltips, url's to further information, etc), as well as user and
training manuals and technical documents. Ideally the data dictionary
could be used to automatically have this be presented in the user
interface without needing much additional coding.

8. Common error handling procedures and methodology which logs
application details when errors occur as well as sending messages to
admins/programmers as needed.

I have already been designing a lot of these elements in my head for a
few years before I even started this job - I was just hoping (and have
to assume) that at least some of them existed in some prepackaged form
by a vendor out there so that I don't have to reinvent the wheel.

One of the databases we will be converting is used to track patient
applications for charity care coverage. Several dozen users enter
patient demographics, and track details such as patient income,
assets, and other coverages they might have, then render a decision
based on several sets of complex criteria. There are about 10
interfaces (both import and export) with external systems, all
currently via flat files and DTS, several of which automatically
generate emails. Users very frequently request ad-hoc reporting,
which the system currently does not support at all (i.e. I write
queries to give them the information they requested).

[CK]

Have you considered your DR (Disaster Recovery) / BC (Business
Continuity)?

Would a server based webapp be more easily deployed in the case of a
loss of a building? Would hosting it offsite allow you to carry on
working with nothing more than a browser?

This is the most important consideration for our applications....

On 7 May, 19:40, "Crisatunity (blog.crisatunity.com)"

[Crisatunity (blog.crisatunity.com)]

Distinctly not succinct. More focus, perhaps more than one thread.
You are going to get either no response or wild-ass unfocused
responses to your blog-style posts.

[Andrew Badera]

My numbers do not correspond to your numbers.

1. Get familiar with Microsoft Patterns & Practices. Get to know the Provider patterns, particularly the MembershipProvider and RoleProvider. Get to know the Logging and ExceptionHandling Application Blocks. Get to know the Data Access Application Block.
2. Get to know Active Directory. It's easy.
3. Get to know both remoting and web services. Trust me, they, too, are easy. This means getting to know serialization a bit as well, which can be a bit kinky.

No, there's probably no prebuilt suite out there that is going to meet all your needs in a cost-effective and low-headache fashion. Get through #1, #2, #3 and I think most of your questions will be answered.

4. Spend time reading MSDN, this list, CodeProject, Coding Horror, Joel on Software, Nielsen & Norman, CodePlex and CodeGallery and Google Code, the CodePlex forums, Channel9.

--

[Charles A. Lopez]

Sounds like a good project.

 

On Mon, May 5, 2008 at 4:14 PM, DevoRevolution <DevoRev...@gmail.com> wrote:

--
Charles A. Lopez
charle...@gmail.com

Bachelor of Arts - Computer Science
New York University
Computing Since 1980

[Art Laubach]

I believe the short answer is pretty simple.

Regardless to whether you are writing a .NET app, or any other type of
event-driven, Object-Oriented language, your general "architecture"
should remain seperate on a functional layer.

Your data transactions should reside on a layer on its own.
Your business logic should reside on a layer on its own.
Your UI representation should reside on a layer on its own.

This allows you to un-plug, and make changes to one layer, without
directly impacting the others (in some or most cases, depending
specifically on how you've written your code).

If you've accomplished this kind of seperation in your architecture,
you can write BOTH types of applications using the same compiled
libraries. Your ASP.NET/C#/VB.NET app can consume the same business
and data layer(s) that you've created.

Another thing to look at is web services. This would allow your .exe
type of applications to be more distributed. However, this doesn't
resolve most issues regarding deployment.

feel free to email me with any other questions.

Good luck!