Real-World Sample Application?

[(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...
--
PeteCresswell

[Cor Ligthert[MVP]]

Pete,

I give you very less change on this, the Net developping tools are changing
almost every 2 years. As you see the by you refered VB6 is already A 4
generations ago language in Visual Basic. Moreover is the way there is
thought about things. Creating an application without bound controls is
doing something in pre history.

Sorry I cannot give you an other advice then try to find samples for the
things you have to do. A sample application complete with by instance Linq
in it, is probably no where to get in a state that it can be seen as a good
sample to start with.

Cor

"(PeteCresswell)" <[e-mail] in bericht
news:5q********************************@4ax.com...

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...
--
PeteCresswell

[Mr. Arnold]

"(PeteCresswell)" <[e-mail] in message
news:5q********************************@4ax.com...

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.

UI layer--Business layer (the business rules)--Data access layer using SQL
server Stored Procedures to do the CRUD. That's
reate-Read-Update-Delete -- no business rules business rules in the
business layer.

You need a good ADO.Net book in VB.

You need a good VB.Net reference book.

For an application in a possible real world kind of situation using VB: ISBN
1-59059-070-8

<http://www.bookfinder.com/dir/i/Building_Client-Server_Applications_With_Vb.Net-An_Example-Driven_Approach/1590590708/>

The book is going to give you what you need to know to build a business
solution in VB.NET.
It's using a Windows forms application that's using IIS with a Web service
as the application gateway between the UI-BL-DAL.

Forget about the IIS part, which you'll have to use, but keep in mind that
the 3 tiers can reside on a workstation with no IIS in use. All you'll want
to see is what is happening with the UI-BL-DAL in action.

The book will give you what you need to get a quick start and come up to
speed fast.

[Jim Rand]

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.

Consider Microsoft Access as the scratch boat for writing data bound
business applications. My experience has been that if an application cost
$10,000 to write in MS Access, the same application would cost $30,000 to
$50,000 to write in VB 6. Why - data binding. In .NET, figure on around
$12,000 to $15,000 - not to shabby!

Bound controls in .NET using binding sources and datasets are .NET's
compelling business story.

Use them.

[clintonG]

And I assumed the objective would in fact be "web development" if such is
not the case most of my advice be it what it was still applies --but--
Windows Forms are now best developed using Windows Presentation Foundation
(WPF) and it is still a wiser choice to learn C# now as there is no question
the desktop and the web are converging into one and most applications given
the opportunity are now being re-engineered and deployed on the web.
Especially anything that can be provided to the general public as Software
as a Service (SaaS).

The Great Oz Has Spoken ;-)
"(PeteCresswell)" <[e-mail] in message
news:5q********************************@4ax.com...

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...
--
PeteCresswell

[Mr. Arnold]

"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:43**********************************@microsof t.com...

Clinton,

Why are you defending C# so hard?

Something wrong with it?

I personally don't see the need for that.

It looks to me as telling people that they should drive an Americain car
because those are absolute much better.

(Which I think they can be in many situations).

The only things that you can't do with VB that you can do with C# is
anonymous delegates and pointers I hear.

Other than that, VB does everything else that C# can do, since they are
both managed code languages that use the .Net Framework. I get offers to do
VB.Net contracting work just like I get for C#.

[clintonG]

I did not say C# was BETTER than VB.NET I recommend learning C# when
becoming a WEB DEVELOPER because Web development demands learning and
mastering JavaScript which is nearly exactly the same language so we learn
two for the price of one so to speak.

Its common sense and a practical business decision.

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>
"Cor Ligthert[MVP]" <no************@planet.nlwrote in message
news:43**********************************@microsof t.com...

>Clinton,

Why are you defending C# so hard?

Something wrong with it?

I personally don't see the need for that.

It looks to me as telling people that they should drive an Americain car
because those are absolute much better.

(Which I think they can be in many situations).

The only things that you can't do with VB that you can do with C# is
anonymous delegates and pointers I hear.

Other than that, VB does everything else that C# can do, since they are
both managed code languages that use the .Net Framework. I get offers to
do VB.Net contracting work just like I get for C#.

[Cor Ligthert[MVP]]

Clinton,

>I did not say C# was BETTER than VB.NET I recommend learning C# when
becoming a WEB DEVELOPER because Web development demands learning and
mastering JavaScript which is nearly exactly the same language so we learn
two for the price of one so to speak.

Its common sense and a practical business decision.

That seems true, however for an experienced programmer JavaScript does not
even look like C# beside the use of brackets.

C# is a strict language, JavaScript is completely the oposite of that.

But more is that as you are searching for samples for Web developping you
get 10 times more VB samples then C# samples.

Have you any idea why that is as I see your statement?

That does not say that I mean that you could not use as an expirienced C#
developper C# for Web development in the same way as VB for Net. However
knowledge of VB for Net will help you then more to understand most samples
as you see them.
What is not difficult because VB for Net looks in my opinion very much more
on C# then JavaScript.

Cor

[(PeteCresswell)]

Per Jim Rand:

>Consider Microsoft Access as the scratch boat for writing data bound
business applications. My experience has been that if an application cost
$10,000 to write in MS Access, the same application would cost $30,000 to
$50,000 to write in VB 6. Why - data binding. In .NET, figure on around
$12,000 to $15,000 - not to shabby!

Those are interesting numbers bc the 1:3/1:5 ratio for VB6
matches up with my own experience when I rewrote a small MS
Access app using VB6. I got 1:3, but all the analysis/design
had already been done when I created the MS Access version.

If the 12-15 number holds up, I must be even more clueless than I
ever imagined about VB.NET, since I assume the back end in the
VB.NET app would be SQL Server and the back end in the MS Access
app would be JET.... and I know from experience that there's
about a 30% penalty when developing the same MS Access app with
SQL Server tables/stored procedures vs JET/Queries.

What I do really isn't MS Access development - it's more like RAD
development where MS Access is my tool of choice.

For several years now, I've been entertaining this fantasy that
if I could get a single real-world app wired in .NET, I could
transition over to using .NET as my tool of choice.

Your numbers seem to support that little fantasy.
--
PeteCresswell

[Mr. Arnold]

"(PeteCresswell)" <[e-mail] in message
news:70********************************@4ax.com...

Per Jim Rand:

>>Consider Microsoft Access as the scratch boat for writing data bound
business applications. My experience has been that if an application cost
$10,000 to write in MS Access, the same application would cost $30,000 to
$50,000 to write in VB 6. Why - data binding. In .NET, figure on around
$12,000 to $15,000 - not to shabby!

Those are interesting numbers bc the 1:3/1:5 ratio for VB6
matches up with my own experience when I rewrote a small MS
Access app using VB6. I got 1:3, but all the analysis/design
had already been done when I created the MS Access version.

If the 12-15 number holds up, I must be even more clueless than I
ever imagined about VB.NET, since I assume the back end in the
VB.NET app would be SQL Server and the back end in the MS Access
app would be JET.... and I know from experience that there's
about a 30% penalty when developing the same MS Access app with
SQL Server tables/stored procedures vs JET/Queries.

What I do really isn't MS Access development - it's more like RAD
development where MS Access is my tool of choice.

For several years now, I've been entertaining this fantasy that
if I could get a single real-world app wired in .NET, I could
transition over to using .NET as my tool of choice.

You need to find out about ADO.Net and what it is about, which is part of
the .Net Framework, and MS Access is just another database provider like
Oracle, MySql, MS SQL Server and many others that ADO.Net supports.

http://en.wikipedia.org/wiki/ADO.NET
http://www.devcity.net/Articles/18/msaccess_sp.aspx

The key is not to know VB because VB is VB for the most part. You know VB.
I have worked with VB from VB3 -VB6 and now VB.Net. VB is VB.

http://www.programmersheaven.com/2/F...ET-Differences
http://www.thescarms.com/vbasic/vb6vsvbnet.aspx

The key to .Net is to know the .Net Framework, using the code in the
library and what is in the namespaces of the .Net Framework. That's the key,
which VB and C# use the .Net Framework, because they are managed code
languages that must use the .Net Framework.

The second key to VB.NET is to understand Object Orientated Programming
concepts. VB 6 brought you some of the way but didn't make it all of the
way. VB.NET is a pure OOP language.

I am not saying you need to go get this particular book, but you need to
find one. Another similar book I used happened to be for C#.

http://www.informit.com/articles/article.aspx?p=25857

You may need to get a book like Head First Design Patterns. The book is in
Java, but it's not that hard to read and understand the OO concepts, which
Java was here first, and the concepts can be implemented in a .Net
solution.

<http://books.google.com/books?id=LjJcCnNf92kC&dq=head+first+design+pattern s&pg=PP1&ots=_9Z_6Ei4tV&sig=4qokbut72LamonnBu55JtH oE_NY&hl=en&sa=X&oi=book_result&resnum=1&ct=result #PPP1,M1>

The third key for .Net is know how to use the search engines like Google or
Dogpile.com, because everything you're looking for in figuring about an
issue in VB.NET or examples have already been done or will be done by
somebody, like that devcity link.

You talk about getting some example of using VB.Net in some kind of a real
world situation. Well, the two books that have been presented to you in
another post are going to put you there fast in what you need to know.

I started in IT in 1971, went to programming in 1980, when to the MS
platform in 1996, when to .Net in 2004 C# first and then VB.

So I guess what I am telling you is this. It's not as hard to go from VB6 to
VB.Net as you seem to think. It's not that hard.

Hey, but also know this.

http://dotnetpowered.com/languages.aspx

[Jim Rand]

Hi Pete,

Here is how I get to the $12K - $15K numbers.

1) The SQL Server table design work is first done using Power Designer. (Buy
a single user instance of Sybase SQL Anywhere 10 and you get Power Designer
for free)

2) All my controls are from DevExpress - the grid is truly awesome.

3) I use data adapters instead of table adapters. The data adapters are
configured using an MS Access program that outputs the same C# code that
Microsoft's data adapter designer generates - only difference is mine works,
writes the SQL code the way I want it, and gets the job done in minutes
instead of hours.

4) I've got a static helper class for handling the updates to the backend
database - one place where all the "interesting" features of ADO.NET are
nicely handled.

I am absolutely delighted with the results I'm getting. So delighted that
I'm no longer offering my MS Access data marshalling technology for new
projects. This was the technology that created disconnected datasets on the
front-end populated by query-pass-throughs with write-backs to the "real"
database using RDO resulting in performance gains of 125 times standard
MS-Access with 100% reliability while still retaining Access's RAD data
binding.

ADO.NET for Windows forms clients uses the exact same idea with identical
performance / reliability results. - wish I had patented the idea.

Enjoy the journey knowing the outcome - rapid application development
because of the binding architecture (the binding source is your best
friend), great multi-user performance and 100% reliability.

Jim

PS: don't get sucked into the OO business object crap for Windows forms
development. Datasets are the way to go. I am exploring business objects
for my web stuff (can we say code generation using XSLT).

"(PeteCresswell)" <[e-mail] in message
news:70********************************@4ax.com...

Per Jim Rand:

>>Consider Microsoft Access as the scratch boat for writing data bound
business applications. My experience has been that if an application cost
$10,000 to write in MS Access, the same application would cost $30,000 to
$50,000 to write in VB 6. Why - data binding. In .NET, figure on around
$12,000 to $15,000 - not to shabby!

Those are interesting numbers bc the 1:3/1:5 ratio for VB6
matches up with my own experience when I rewrote a small MS
Access app using VB6. I got 1:3, but all the analysis/design
had already been done when I created the MS Access version.

If the 12-15 number holds up, I must be even more clueless than I
ever imagined about VB.NET, since I assume the back end in the
VB.NET app would be SQL Server and the back end in the MS Access
app would be JET.... and I know from experience that there's
about a 30% penalty when developing the same MS Access app with
SQL Server tables/stored procedures vs JET/Queries.

What I do really isn't MS Access development - it's more like RAD
development where MS Access is my tool of choice.

For several years now, I've been entertaining this fantasy that
if I could get a single real-world app wired in .NET, I could
transition over to using .NET as my tool of choice.

Your numbers seem to support that little fantasy.
--
PeteCresswell

[Mr. Arnold]

"Jim Rand" <ji*****@ix.netcom.comwrote in message
news:eK**************@TK2MSFTNGP04.phx.gbl...

>

PS: don't get sucked into the OO business object crap for Windows forms
development. Datasets are the way to go. I am exploring business objects
for my web stuff (can we say code generation using XSLT).

Yeah if you do it right, then the Windows form solution shouldn't be aware
of the BL as the UI is loosely coupled to the BL, and it doesn't matter what
uses the BL and what is coming back to the UI such as dataset, collection,
arraylist, BO etc from the BL or going down to the BL, etc. The same BL
can be used by a Windows or WEB forms solution, by the usage of interfaces,
which is OO programming. A dataset is an object, an int, string, long etc
are objects everything in .Net is an object.

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

[Jim Rand]

All of our business logic is implemented in SQL Server triggers and stored
procedures. If a business rule is violated, we raise an error and roll back
the transaction as in:

RAISERROR ('Business Logic: Event checked out. Unable to change Event
Registered By Date', 14, 1);
ROLLBACK;

This way we can use a mix of development environments - php for the web and
..NET for the Windows form. Each application can then decide how they want
to handle the error.

Jim

"Mr. Arnold" <MR. Ar****@Arnold.comwrote in message
news:e9**************@TK2MSFTNGP03.phx.gbl...

>
"Jim Rand" <ji*****@ix.netcom.comwrote in message
news:eK**************@TK2MSFTNGP04.phx.gbl...

>>

PS: don't get sucked into the OO business object crap for Windows forms
development. Datasets are the way to go. I am exploring business objects
for my web stuff (can we say code generation using XSLT).

Yeah if you do it right, then the Windows form solution shouldn't be aware
of the BL as the UI is loosely coupled to the BL, and it doesn't matter
what uses the BL and what is coming back to the UI such as dataset,
collection, arraylist, BO etc from the BL or going down to the BL, etc.
The same BL can be used by a Windows or WEB forms solution, by the usage
of interfaces, which is OO programming. A dataset is an object, an int,
string, long etc are objects everything in .Net is an object.

http://www.polymorphicpodcast.com/

click 'Shows'

click 'Design Patterns Bootcamp: Model View * Patterns*

view parts 1-5

You can use Google to get more information about this or find books.

[Mr. Arnold]

"Jim Rand" <ji*****@ix.netcom.comwrote in message
news:Ou****************@TK2MSFTNGP05.phx.gbl...

All of our business logic is implemented in SQL Server triggers and stored
procedures. If a business rule is violated, we raise an error and roll
back the transaction as in:

RAISERROR ('Business Logic: Event checked out. Unable to change Event
Registered By Date', 14, 1);
ROLLBACK;

What? You think that's the only way to do it. You don't know that you can
put ADO.Net in a transaction mode?

Do you even know what MVP, MPF, and WCF is about or even Workflow?

This way we can use a mix of development environments - php for the web
and .NET for the Windows form. Each application can then decide how they
want to handle the error.

This has nothing to do with handling of errors. It's about OO programming
and the use of objects, not error trapping.

Nothing against what you're using but you're trying to stagnate the man out
of the gate, when he needs to open his eyes.
..

[Jim Rand]

What? You think that's the only way to do it. You don't know that you can
put ADO.Net in a transaction mode?

Of course I do. Very powerful for guaranteeing atomicity which keeps me from
being sued for screwing up business transactions.

>
Do you even know what MVP, MPF, and WCF is about or even Workflow?

Hmmm. Let me see - MVP - sort of like MVC (model-view-controller) which has
some great implementations in Java but came late to .NET.

MPF - Managed Package Foundation (got me on that one) - new in VS2008 which
I don't have yet - waiting for SP1 currently in beta

WCF - Windows Communication Foundation - yes, I have Chris's book and have
major plans for this one since it's got all the plumbing dealing with
threading for writing really cool services that will save my clients big
bucks.

Workflow - interesting one. I'm reviewing that in conjunction with
SharePoint.

For other inititals, how about MIT. Do you know that one? [little bit of
sarcasm :-)]

>This way we can use a mix of development environments - php for the web
and .NET for the Windows form. Each application can then decide how they
want to handle the error.

This has nothing to do with handling of errors. It's about OO programming
and the use of objects, not error trapping.

We were talking about business logic and raising events across application
boundaries are clearly in this domain. And yes, you put business logic in
nice contained classes anywhere in the application stack where appropriate.

Nothing against what you're using but you're trying to stagnate the man
out of the gate, when he needs to open his eyes.

No, I'm not trying to stagnate the man out of the gate. I'm giving him a
positive heads up about technology that is going to meet his objectives.

And as far as OO programming - of course I use that.

Pete Cresswell has a legitimate question - is .NET a good business answer
for providing solutions to IT questions? To answer that question, you can
invest a lot of time into the architecture (which I did) having the faith
that it is good stuff. You can also ask someone else who has gone there.

So Pete, for replacing your Access programming, go for it. The numbers
work. Be aware, however, there are some real minefields. Think datasets,
binding sources and good controls. Learn ADO.NET. Autoincrement keys are a
bear but once you have figured out the data marshalling layer, they are a
piece of cake. Also, stay away from the notion of TableAdapters. Don't waste
any time looking at the Enterprise Library. Do look at log4net. No project
goes out of here without it.

[Mr. Arnold]

"Jim Rand" <ji*****@ix.netcom.comwrote in message
news:%2****************@TK2MSFTNGP05.phx.gbl...

>

>What? You think that's the only way to do it. You don't know that you can
put ADO.Net in a transaction mode?

Of course I do. Very powerful for guaranteeing atomicity which keeps me
from being sued for screwing up business transactions.

You made me wonder.

>

>>
Do you even know what MVP, MPF, and WCF is about or even Workflow?

Hmmm. Let me see - MVP - sort of like MVC (model-view-controller) which
has some great implementations in Java but came late to .NET.

We're not talking Java. This is a .Net NG, and I have used it, fabulous.
It doesn't matter when it came as long as it works.

>
MPF - Managed Package Foundation (got me on that one) - new in VS2008
which I don't have yet - waiting for SP1 currently in beta.

Oops, I meant WPF which I have seen demo. I have not used it, but very
intersting. I'll look up this MPF. :)

>
WCF - Windows Communication Foundation - yes, I have Chris's book and have
major plans for this one since it's got all the plumbing dealing with
threading for writing really cool services that will save my clients big
bucks.

Well, don't make the mistake I have seen with over architecting with WCF,
what a nightmare.

This tool will help you, which can be installed with VS 2008.

http://msdn.microsoft.com/en-us/library/cc487895.aspx

>
Workflow - interesting one. I'm reviewing that in conjunction with
SharePoint.

For other inititals, how about MIT. Do you know that one? [little bit of
sarcasm :-)]

You're not funny. :)

>

>>This way we can use a mix of development environments - php for the web
and .NET for the Windows form. Each application can then decide how
they want to handle the error.

This has nothing to do with handling of errors. It's about OO
programming and the use of objects, not error trapping.

We were talking about business logic and raising events across application
boundaries are clearly in this domain. And yes, you put business logic in
nice contained classes anywhere in the application stack where
appropriate.

Business logic is more than raising events across tiers logical or physical,
and there are several types of business objects in the business layer that
do things, if one has used the technology effectively, like unanchored smart
business objects that persist them self with the database coming across
logical or physical n-tier boundaries.

>

>Nothing against what you're using but you're trying to stagnate the man
out of the gate, when he needs to open his eyes.

No, I'm not trying to stagnate the man out of the gate. I'm giving him a
positive heads up about technology that is going to meet his objectives.

>
And as far as OO programming - of course I use that.

Pete Cresswell has a legitimate question - is .NET a good business answer
for providing solutions to IT questions? To answer that question, you can
invest a lot of time into the architecture (which I did) having the faith
that it is good stuff. You can also ask someone else who has gone there.

I have gone there, done that, and seen that. I have used .Net in all
aspects of business solution development Windows Desktop, Web applications
such as ASP.Net and Web services and WCF, Console, and NT service, both VB
and C#. I have a pretty good idea what .Net can do. I came out the gate
with architecture starting with CSLA for .Net, actually CSLA using VB6 for
COM/COM+ n-tier solutions back in the day, Windows DNA, ect.

The man doesn't need to be told that BL and BO(s) are crap, because they are
not crap, if one knows how to use the technology, which I have seen
implemented at many client sites, not many but all of them.

Datasets have got their place in the grand scheme of things. ;-)

Whoever that Chris guy is great, but you don't shun the knowledge of someone
like Lhohka and business objects, which the concepts in all the enviroments
and has served me well.

If you're reading this Pete, then go get the books, because that's the only
way to pick it up fast.