P
(PeteCresswell)
Some time within the next nine months, there's a pretty good
chance I'll have the "opportunity" to port a bond trading system
that I wrote - whose front end is currently MS Access - to .NET.
Quotes bc I need this like I need another hole in the head.
But in the words of one of my esteemed colleagues: "I don't sell
programming; I sell happiness." And if this will make my
clients happy, that's what floats my boat in the long run.
Said port will be begun *only* after I've moved the back end and
as many of the business rules I can to SQL Server tables/stored
procedures.
I've got a lot of development experience, but I'll be going into
..NET stone cold and, compared to a lot of other developers, I'm
not exactly the brightest bulb on the tree.
Experience suggests that I learn the fastest/easiest by cloning
something of quality that works and "making it mine" by rewriting
it and playing around with it as I go.
Can anybody point me to a "real world" sample application written
in .NET with a SQL Server back end?
FWIW I would not, for one moment, call the "North Wind"
application that ships with MS Access "real world".
Not even close... More like a bad example, even...
What I'm looking for would:
---------------------------------------------------------------
1) Have a SQL Server back end with user-written stored
procedures. i.e. Nothing auto-generated.
2) Would NOT contain any wizard-generated code or objects of any
kind.
3) Would NOT rely to any large extent on data-bound controls.
Although this may be emphasizing my ignorance of .NET,
I'm coming from the statement somebody, somewhere only
half-jokingly made about bound controls in VB6: "Bound
controls are the spawn of Satan."
Actually, a couple of bound controls would probably
be a good thing just to see how they're implemented... but
unless bound controls are "the thing" in .NET, I'd want most
controls most of the time tb unbound.
4) Name it's objects/fields accordingly to some widely-accepted
set of naming conventions.
5) Have at least one screen that:
- Lists items in a hierarchical list that the user can
walk and select the item whose detail is tb shown from.
- Allows the user to specify criteria for that
list.
- Remembers/restores the screen's complete state (including
any selection criteria for the list) the next time
it is opened.
- Shows details of the currently-selected parent record and,
say, all records in at least two or three child tables on
the same screen as the hierarchical list is on. i.e.
the user can walk the list and see the screen change
each time a different list item is selected.
- Has "Browse", "Add", and "Edit" modes where entering
"Add" or "Edit" exposes "Save" and "Cancel" buttons and
"Browse" does not allow the user to type anything in to
any field or update any combo box.
- Performs error checking across the current parent record and
the child tables, where the conditions of the checking
are interdependent across parent/child tables and across
other parent/child records in the database.
- Does some edit checking on it's own.
- Pushes at least some of the edit checking back to
SQL Server and allows violations to bubble back up
to said screen - which handles them gracefully and
presents them to the user the same as locally-discovered
errors are.
- Provides for both "Fatal" (record cannot be saved until
user fixes error) and "Warning" (record can be saved,
but user gets a warning) errors.
- Displays edit-checking results to the user
by highlighting the fields in error and displaying the
reason(s) for the error(s).
5) Implement an error trapping scheme such that when something
(either VB code or SQL Server) throws an error, that
error is trapped gracefully and logged to a .txt file
along with the procedure where it happened, line number
if applicable, and so-forth.
6) Contain at least a few reports written using whatever the
commonly accepted tool is.
"Commonly-accepted" bc last time I looked into .NET (some
years back) it seemed like the tool that shipped with it was
ignored/considered inadequate by most people.
They bought the "real" version of the same tool separately.
7) Implement some method of automagically/transparently updating
user's installs of the application if/when parts of it are
changed.
8) Implement the flip side of #3: a method of rolling back
changes that might have been elevated to production by mistake
and/or contain errors that require immediate rolling back to
the prior version.
---------------------------------------------------------------
Maybe something from Wrox?
I don't mind shelling out a few hundred bucks for this if it will
meet at least most of the above requirements.
I'm also ready to hear that at least some of the abovementioned
requirements are misguided... and I'd appreciate hearing that and
the reasons why too...
chance I'll have the "opportunity" to port a bond trading system
that I wrote - whose front end is currently MS Access - to .NET.
Quotes bc I need this like I need another hole in the head.
But in the words of one of my esteemed colleagues: "I don't sell
programming; I sell happiness." And if this will make my
clients happy, that's what floats my boat in the long run.
Said port will be begun *only* after I've moved the back end and
as many of the business rules I can to SQL Server tables/stored
procedures.
I've got a lot of development experience, but I'll be going into
..NET stone cold and, compared to a lot of other developers, I'm
not exactly the brightest bulb on the tree.
Experience suggests that I learn the fastest/easiest by cloning
something of quality that works and "making it mine" by rewriting
it and playing around with it as I go.
Can anybody point me to a "real world" sample application written
in .NET with a SQL Server back end?
FWIW I would not, for one moment, call the "North Wind"
application that ships with MS Access "real world".
Not even close... More like a bad example, even...
What I'm looking for would:
---------------------------------------------------------------
1) Have a SQL Server back end with user-written stored
procedures. i.e. Nothing auto-generated.
2) Would NOT contain any wizard-generated code or objects of any
kind.
3) Would NOT rely to any large extent on data-bound controls.
Although this may be emphasizing my ignorance of .NET,
I'm coming from the statement somebody, somewhere only
half-jokingly made about bound controls in VB6: "Bound
controls are the spawn of Satan."
Actually, a couple of bound controls would probably
be a good thing just to see how they're implemented... but
unless bound controls are "the thing" in .NET, I'd want most
controls most of the time tb unbound.
4) Name it's objects/fields accordingly to some widely-accepted
set of naming conventions.
5) Have at least one screen that:
- Lists items in a hierarchical list that the user can
walk and select the item whose detail is tb shown from.
- Allows the user to specify criteria for that
list.
- Remembers/restores the screen's complete state (including
any selection criteria for the list) the next time
it is opened.
- Shows details of the currently-selected parent record and,
say, all records in at least two or three child tables on
the same screen as the hierarchical list is on. i.e.
the user can walk the list and see the screen change
each time a different list item is selected.
- Has "Browse", "Add", and "Edit" modes where entering
"Add" or "Edit" exposes "Save" and "Cancel" buttons and
"Browse" does not allow the user to type anything in to
any field or update any combo box.
- Performs error checking across the current parent record and
the child tables, where the conditions of the checking
are interdependent across parent/child tables and across
other parent/child records in the database.
- Does some edit checking on it's own.
- Pushes at least some of the edit checking back to
SQL Server and allows violations to bubble back up
to said screen - which handles them gracefully and
presents them to the user the same as locally-discovered
errors are.
- Provides for both "Fatal" (record cannot be saved until
user fixes error) and "Warning" (record can be saved,
but user gets a warning) errors.
- Displays edit-checking results to the user
by highlighting the fields in error and displaying the
reason(s) for the error(s).
5) Implement an error trapping scheme such that when something
(either VB code or SQL Server) throws an error, that
error is trapped gracefully and logged to a .txt file
along with the procedure where it happened, line number
if applicable, and so-forth.
6) Contain at least a few reports written using whatever the
commonly accepted tool is.
"Commonly-accepted" bc last time I looked into .NET (some
years back) it seemed like the tool that shipped with it was
ignored/considered inadequate by most people.
They bought the "real" version of the same tool separately.
7) Implement some method of automagically/transparently updating
user's installs of the application if/when parts of it are
changed.
8) Implement the flip side of #3: a method of rolling back
changes that might have been elevated to production by mistake
and/or contain errors that require immediate rolling back to
the prior version.
---------------------------------------------------------------
Maybe something from Wrox?
I don't mind shelling out a few hundred bucks for this if it will
meet at least most of the above requirements.
I'm also ready to hear that at least some of the abovementioned
requirements are misguided... and I'd appreciate hearing that and
the reasons why too...
]