Well, it certainly sounds like you've thought hard about your problem,
and have taken things like minimizing database roundtrips into
consideration, which to me means you're much more likely to successfully
build large-scale systems than most I encounter!
> >It sounds like you've gotten around th
Two areas I haven't seen addressed in this separate or stick
logic/adonet code discussion:
1) Code generation. Data access code generally alters only in terms of
the name of the stored procedure (or inline SQL) and parameters. It's
not very difficult to generate this code (as evidenced by the n
[see in-line]
>From: Craig Andera <[EMAIL PROTECTED]>
>Reply-To: "Moderated discussion of advanced .NET topics."
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
>Date: Fri, 6 Sep 2002 16:17:06 -0
e
DAL within the Business layer code assembly.
Later
Keith
-Original Message-
From: Jon Stonecash [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 1:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
Craig,
Performance and scalabilit
the Business layer code assembly.
Later
Keith
-Original Message-
From: Jon Stonecash [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 1:35 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
Craig,
Performance and scalability are always with
Hmm. Here's the thing, though: if you want to minimize database
roundtrips, you have to have sprocs that know what the business layers
wants. Which means that the data layer has to know, too. Which means
that the business layer is essentially coupled straight to the database.
It sounds like you'
> 1. What if you decide to use Oracle instead of MS SQL? Since the
Business
> logic hasn't change there is no need to touch any part of that code
but
> the
> Data layer is now going to have to change where and maybe how it pulls
the
> data. Keeping the layers separate garuntees that the Business
ly-To: "Moderated discussion of advanced .NET topics."
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
>Date: Fri, 6 Sep 2002 09:03:40 -0400
>
> > We used stored procedures extensively. We chose to limit
g you need item 1
Francis X. Knebels
Merck Vaccine Division
-Original Message-
From: Martin H. Henderson [mailto:[EMAIL PROTECTED]]
Sent: Friday, September 06, 2002 9:30 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
Personally I think the Business
-
From: Moderated discussion of advanced .NET topics.
[mailto:[EMAIL PROTECTED]]On Behalf Of Craig Andera
Sent: Thursday, September 05, 2002 1:40 PM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
I'm not sure I entirely follow what you're saying.
> We used stored procedures extensively. We chose to limit the logic of
> each
> stored procedure to one database.
I'm not sure how you'd do anything else.
> The data layer objects (which were in
> separate components/assemblies pulled data out of the required data
> stores,
> performed some co
w else one would approach this.
Jon Stonecash
>From: Craig Andera <[EMAIL PROTECTED]>
>Reply-To: "Moderated discussion of advanced .NET topics."
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
>
or.
Perhaps we're in agreement - I didn't quite follow what you said.
> -Original Message-
> From: Moderated discussion of advanced .NET topics. [mailto:ADVANCED-
> [EMAIL PROTECTED]] On Behalf Of Jon Stonecash
> Sent: Thursday, September 05, 2002 1:56 PM
> To: [EMAIL P
uot;Moderated discussion of advanced .NET topics."
><[EMAIL PROTECTED]>
>To: [EMAIL PROTECTED]
>Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
>Date: Thu, 5 Sep 2002 10:04:09 -0400
>
> > In many (maybe most?) enterprise systems, tiers are built by di
> In many (maybe most?) enterprise systems, tiers are built by different
> developers. E.g. HTML/ASP/ASP.NET is written by one guy, business
logic
> (VB
> com(+), VC/ATL com(+), C#. VB.NET) by another, and database structure
and
> stored procs - by yet another.
>
> Yet, for scalable systems, when
>Which reminds me of a question I've really been anxious to ask for quite
>some time:
>
>In many (maybe most?) enterprise systems, tiers are built by different
>developers. E.g. HTML/ASP/ASP.NET is written by one guy, business logic (VB
>com(+), VC/ATL com(+), C#. VB.NET) by another, and database
In many (maybe most?) enterprise systems, tiers are built by different
developers. E.g. HTML/ASP/ASP.NET is written by one guy, business logic (VB
com(+), VC/ATL com(+), C#. VB.NET) by another, and database structure and
stored procs - by yet another.
Yet, for scalable systems, when implementing
- Original Message -
From: "Peter Foreman" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 15, 2002 11:53 PM
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
[del]
> Relational systems are at the heart of developing highly scala
4, 2002 9:21 AM
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
Oops, somehow hit send accidentally, and half my message disappeared at
the same time. Gotta learn how to work this keyboard thing. ;-)
Anyway, this system seems susceptible to a trivial
taken care of by the client making some
> >sort of hash out of the method signature and the server validating
the
> >hash with the actual method requested.
> >
> >So far this has worked out fabulously for us.
> >
> >--b
> >
> >Bryan Batchelder
> >eBusin
alidating
the
> >hash with the actual method requested.
> >
> >So far this has worked out fabulously for us.
> >
> >--b
> >
> >Bryan Batchelder
> >eBusiness Consultant
> >ConnectWise, Inc.
> >813-935-7100 x 425
> >
> >
> >
&g
"you _do_ require them to authenticate, right?"
Actually, shamefully to admit, no. I am unfamiliar with authentication methods other
then the basic application login where I store a hashed PW in the DB and verify two
hashed values and go from there. I started to read up on it and am getting a
Still speaking about COM+ vs SQL Server transactions, how problematic can be
using a class like the following (some kind of a decorator for a SQLTrans
object)? It's probably full of minor & MAJOR bugs but that's not the point,
the point is how usable can be something like this? I'm specially sensi
ons)
- Stateful objects aren't such a bad ideia after all
- ... :)
Regards,
RQ
-Original Message-
From: Craig Andera [mailto:[EMAIL PROTECTED]]
Sent: quarta-feira, 15 de Maio de 2002 20:24
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A
Original Message-
From: Craig Andera [mailto:[EMAIL PROTECTED]]
Sent: Donnerstag, 16. Mai 2002 00:57
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
> I don't think spanning a transaction across multiple method
> calls on the business tier is a probl
tneward
http://www.clrgeeks.com/tneward
- Original Message -
From: "Sinnott, John" <[EMAIL PROTECTED]>
To: <[EMAIL PROTECTED]>
Sent: Wednesday, May 15, 2002 1:23 PM
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
> I don't think spanning a trans
> I don't think spanning a transaction across multiple method
> calls on the business tier is a problem as long as all those
> alls are wrapped in a single call to the business tier that
> starts and commits the transaction.
Given that your database and your business tier machines are almost
neve
> This is really one of the best lists for .Net, thanks
> everyone for all the usefull tips I've been reading the last
> few days. But I've a question about this one. If we don't
> need distributed transactions, even if you have just one SQL
> Server database, and we choose not to use COM+ service
--- Thomas Tomiczek <[EMAIL PROTECTED]> wrote:
> Re 1: being prepared demands transaction support. How do you judge a
> black box component used by a number of customers on the same code basis
> on a "case by case basis"?
As a buyer or a developer of the component?
As a buyer - how can I integra
cs0205.asp
Richard
> -Original Message-
> From: Moderated discussion of advanced .NET topics.
> [mailto:[EMAIL PROTECTED]]On Behalf Of Rui Dias
> Quintino
> Sent: 15 May 2002 15:30
> To: [EMAIL PROTECTED]
> Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle T
soft MVP C#/.NET)
-Original Message-
From: Peter Foreman [mailto:[EMAIL PROTECTED]]
Sent: Mittwoch, 15. Mai 2002 14:59
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
--- Thomas Tomiczek <[EMAIL PROTECTED]> wrote:
> Re 1: you also can NOT ass
--- Thomas Tomiczek <[EMAIL PROTECTED]> wrote:
> Re 1: you also can NOT assume you will not at any point in the future
> HAVE to coordinate a transaction with a different component. So you have
> to be prepared.
That's exactly right, you can not assume either way, which is why jumping into a
des
2:41 PM
To: 'Moderated discussion of advanced .NET topics.'
Subject: RE: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
Hi,
Below are just my thoughts about COM+ declarative transactions that
could happen to be just my speculations without any relation to any
official posi
Hi,
Below are just my thoughts about COM+ declarative transactions that
could happen to be just my speculations without any relation to any
official position of my employer or associates, bla, bla, bla... ;-).
Ie: don't read it if you don't need it ;-).
COM+ transactions appear to be a very
--- Thomas Tomiczek <[EMAIL PROTECTED]> wrote:
> Hm, if you "can have a layer of transactional components without COM+" -
> what d you use as DTC?
Firstly, if you have multiple RMs then I'd go with COM+/DTC.
However, the DTC is considerable overhead in the single RM case. Code transaction
star
not a competitor to DCOM, sorry.
Regards
Thomas Tomiczek
THONA Consulting Ltd.
(Microsoft MVP C#/.NET)
-Original Message-
From: Dan Green [mailto:[EMAIL PROTECTED]]
Sent: Samstag, 11. Mai 2002 10:23
To: [EMAIL PROTECTED]
Subject: Re: [ADVANCED-DOTNET] Help Architecting A Middle Tier
> From: Thomas Tomiczek
> Sent: Tuesday, 7 May 2002 11:18 PM
>
> [ ... snip ... ]
>
> *** Thought of ServicedComponents?
> Remoting is not on par feature-wise yet
Thomas,
Which of the extra features in COM+ do you think are going to make a
difference to Jerry's physically-partitioned architectur
Inline :-) And do yourself a favor and get some serious consulting.
-Original Message-
From: Jerry Abbott [mailto:[EMAIL PROTECTED]]
Sent: Dienstag, 7. Mai 2002 14:23
To: [EMAIL PROTECTED]
Subject: [ADVANCED-DOTNET] Help Architecting A Middle Tier
Our company is a ecommerce company
38 matches
Mail list logo
