Architecture

[Tom]

Hello,

I have a Windows form application that currently uses a database local to
the machine it is running on. We are planning on setting this application
up for a multi-user environment, so I would like to change to a 3-tier
architecture application for scalability:

1. My Client
|
2. My Business Logic Server (The client connects here)
|
3. My database server

We may also create another web form client in the future, and I would also
like that to connect to the business logic server as well.

My question is, what type of communication do you guys recommend between the
exist client and the business logic server?

1. If I use .NET remoting, can an ASP .NET page easily utilize the .NET
remoting code if I create an additional web form in the future?

2. If I setup the logic server to provide web services to clients, I have
heard that web services don't support transactions across multiple database
servers, so if I can't use web services, what should I use?

Any help is greatly appreciated. Thanks.
-- Tom

 

[sloan]

WCF.

Then you can expose WCF endpoints (to the same exact code) as you need them.

http://sholliday.spaces.live.com/Blog/cns!A68482B9628A842A!158.entry

Downloadable code there.

..........

My example (above link) is for a DotNet to DotNet world.

If your WCF needs to expose non DotNet end points (java, asp,
whatever)....then don't do it as my example does.

 

[Tom]

Thanks sloan. That looks like exactly what I want, but I do have another
question...

I'm going to design it so that the presentation layer (client) code could
exist on 1 machine, the business logic layer could exist on another machine,
and the data layer could exist on a third machine. Alternatively, they want
it so that any 2 layers could exist on the same machine together, or to have
all three layers exist on the same machine.

If I use WCF, do you foresee any problems with that requirement?

Thanks again.

 

[sloan]

You can do that if you'd like.

I personally think its a little overkill....the BLL and DAL seperation.

....

If you go with custom business objects and collections....then having your
BLL and DAL together is ok..you're seperating those for MAINTENANCE reasons,
rather than uber scaling reasons.

One issue (esp with my example) is that you CANNOT serialize something like
an IDataReader.
So you create the IDataReader in teh DAL, and you use the IDataReader in the
BAL..then you close it just as fast as you can.
When you take this approach....I prefer to have those 2 "layers" together on
the same machine.

When you talk about remoting boundaries...you MUST remember what you can and
cannot serialize.

IDataReader = no serializing.

Now, you could have the BLL/DAL combo that I speak of...AND have
BusinessLogicProcessing machines as another Tier.
But you got to sit down with a big whiteboard and figure that kind of stuff
out.

OR ( I don't like this idea, but here goes)
You could do it your way...and send (strong) DataSets over the wire from/to
your DAL to/from you BLL.
I don't like that idea (because DataSets don't serialize as nicely), but its
~an~ idea.


With WCF, everything is a Service. When you want to deploy your code, and
you want it on one machine, you can choose NamedPipes.
My sample actually does this. You get 2 endpoints, one is named pipes and
one is a httpService. (Just as a demo for kicks to show you what you can
do).

...

Personally, (and what I'm doing right now) is I'd drop the BAL/DAL
seperation. That's a maintanance seperation more than a remoting boundary
seperation on my book.

Let the BLL use/consume the DAL locally, and create your serializable
objects as fast as it possible can...and then remote those.

But that's my take, I'm def not omniscient with this stuff.

........

as another source, you can try the
msdn.microsoft.com/stocktrader/ app as well. I'd try to get the 1.1
refresh. But there is ALOT going on with that demo....its not as short as
my samples.

Good luck.

 

[Ravi Bhavnani]

what type of communication do you guys recommend

between the exist client and the business logic
server?

I *strongly* recommend using WCF. It's fast, flexible and easy to use.

/ravi