Re: Need a sanity check on CAO and lifetime
- From: peter <apvx95@xxxxxxxxxxxxx>
- Date: Fri, 08 Jul 2005 18:15:37 +0100
Roy Chastain wrote: <snip />
Now, you may wonder why go to this effort. Upside It allows me to have all the actual business logic reside only in the server side code. Downside It appears overly complicated.
Comments and discussion, PLEASE.
<snip />
Hi Roy,
I'm always up for commenting and discussing, so here's my 2c worth (dwy geiniogwarth (Welsh))
Firstly a confession. I don't understand your code on a first reading. However I think I understand what you're trying to do if what you say above is the long and the short of it.
We do exactly this. We have asp.net code running on a web server. This code does no business logic processing or data accessing. For business logic it calls a remote object on the application server: usually one business logic object per application but there is some sharing.
For data access, the presentation layer calls either the business logic component (if there is some business logic processing to do on the data first), or calls a data access component directly. There is often a data access component for the application, but there is a lot more sharing in this area than with business logic.
If the presentation layer calls the business logic layer as an intermediary, the business logic component calls the data access component locally (i.e. not across any appDomain boundaries) - since both sets of components are physically on the same machine.
The web server is not on the domain. The application server is on the domain, so it makes trusted calls to the database which is on another server on the domain. Neither the app server nor the database server have an external IP address. The app server only accepts calls from the web server.
Data access objects do all their own data cleansing (to avoid injection attacks and the like). Generally this means checking any input to the methods of the data access component against a regex, and calling stored procedures on the database using parameters rather than constructing SQL on the fly.
We use only tcp channels, but we produce our proxies using soapsuds even where the documentation says you can't. You can in all the situations we have met so far.
We always configure remoting using config files. We configure DLLs, when necessary, using AssemblySettings (Google for it if you're interested).
We rarely use CAOs because they are generally agreed to be more complex than SAOs, and we make all our SAOs stateless. We don't use the factory pattern, but we will probably move towards it if it looks as though the number of ports open for remote objects is getting unwieldy.
For CAOs we use property sets to set the state and only use the default constructors.
All our assemblies are signed and installed in the GAC. All our remote objects are hosted in Windows services.
So, to cut a long story short, I don't understand why you need anything very complicated to acheive what you appear to want to acheive.
HTH
Peter .
- References:
- Need a sanity check on CAO and lifetime
- From: Roy Chastain
- Need a sanity check on CAO and lifetime
- Prev by Date: Memory Leak
- Next by Date: w2k3, IIS and remoting
- Previous by thread: Need a sanity check on CAO and lifetime
- Next by thread: Memory Leak
- Index(es):
Relevant Pages
|
