|
Arthur Asks:
I'm trying to decide if the client for an app I'm designing would best be
built as a standalone VB executable or a web-based ASP app.
The application will basically consist of a SQL Server DB housed off site and
accessible via TCP/IP. The client will be used to view data, modify data
etc.--nothing too fancy. There will only be a half-dozen users or so. Having
never built a VB app before, I'm just assuming that a VB client will run
faster and leaner than an ASP app (with all its requisite, bandwidth-hungry
HTML). But I really don't know. Giving users the convenience of connecting
to the app from any web browser on any machine might be nice, but I'm really
more concerned about performance.
Anybody have any thoughts/experience/advice about such a decision?
Rob Replies:
If you don't have to put it on the Web, then don't.
What i would do, is develop a good middle tier (all your business logic),
and then the VB App around it for presentation. Then, when you want to (if
need be) port it over to the Web, you will have very little porting to do.
Kevin Joins In:
I am also in a similiar situation where I will be having VB and Web front
ends accessing the same middle tier. I am currently doing a lot of research
to find out the best way to build the middle tier. I came across an
article on MSDN about a Engine-Collection-Class design
(http://msdn.microsoft.com/library/default.asp?URL=/library/techart/desipat.htm) that looks interesting. The whole problem I am having is what
distributed protocol to use, DCOM or SOAP? How have you normally designed
your apps? Do you know of any good articles online that may be of help?
Rob Explains:
If you can guarantee that you will always be faced with distribution/integration on M$ platforms then maybe DCOM would be a solution. Otherwise SOAP/Web Services is a good alternative.
http://www.aspfree.com/devlinks
Categories: SOAP, Web Services (WSDL), DCOM
Dan Feels Differently:
I would say that the ASP solution would be the better way to go. You have
one centralised system that you can change, support and update easier than
several VB apps lying around. The ASP html doesn't have to be bandwidth
hungry, just be careful with your code.
As for the speed. If you host the ASP app on a decent machine then it could
run faster than a desktop VB App.
Just my thoughts anyway...
Grateful, Kevin Replies:
Thanks for the links. I'll have to dig through the SOAP resources. I guess
my biggest issues that I have to find out about is how do you restirct
access to a soap service. I can guarantee that I will always be using MS
platforms and my original thought was DCOM, but with everything moving to
web services, I wonder if that would be a more flexible approach for this
application?
Rob Goes Into High Gear:
Flexible yes, cross platform yes.
If your biggest issue is to restrict access, then it's not really a
problem. Basically the way a standard Web service works (built with the M$
SOAP SDK), is that it makes an HTTP request over the wire. In Version 1,
it was handled mostly by either an ASP page, and an include, (or an ISAPI
filter), and in Version 2, it is handle basically exclusively by a COM object.
What I'm trying to say is, when it comes down to it, the easiest way to
limit access to a web service can be done the same exact way you would
limit access to any other .ASP (server resource) on your site. Some sort
of login mechanism. With MSXML3, which has been out for quite some time,
and was a big improvement over V2, you have the capabilities of SSL for
your secure communication mechanism.
The beauty of it all, is that you can easily hook into your standard
session manager (we just hope that it is not based on cookies / session
object!!)
Arthur Rejoins the Discussion:
Hi guys (Robert, Daniel, Kevin)
Thanks for the great discussion...as always, you've got wonderful, helpful
suggestions!
Okay, now I'm really going to reveal my ignorance:
When you talk about developing a good middle tier, does this mean putting
all the business logic in, say, SQL Server itself? Or writing some
standalone server components that would do this? Or both?
So far, I've been focused on doing ASP stuff, and all my logic is just
embedded within each page as needed--not at all portable! I've seen at least
one example where an ASP developer put all his logic in a separate, giant
ASP doc, then included that at the top of every presentation page...is this
more along the lines of what you're talking about?
Rob Breaks It Down:
Tier 1: Presentation
-no business logic
-just transforms calls to the middle tier into something
appropriate for your presentation
deployment (HTML, VB Forms, etc..)
-no data
-ASP, php, jsp, etc..
Tier 2: Business Logic
-no presentation logic
-queries the DB tier (tier 3)
-transforms calls from the DB, into something useable for the
presentation tier
-all business logic/rules (for example: 5+3 = 8 )
-COM, DCOM, Beans, etc..
Tier 3: Database
-no presentation, or business rules
-just stores & retrieves data
-DBMS (SQL Server, oracle, access, etc..)
Develop things this way, just in case, you wish to replace #3, its just a
matter of plugging in a new database (change your conenction string, or
whatever)..or if you want to send content to a phone/pda/whatever, you just
rewrite a bit on tier 1.
Kevin Takes It A Step Further:
The tiers are broken down to four levels in my case
Tier 1 is the presentation layer. Your HTML/ASP or in my case VB front
ends. There is no DB access done here, just the presentation
Tier 2 is the business logic layer. This uses the 3rd tier data access
component to query the DB for the data and makes the data more presentable
for the presentation layer. I am mapping one business object to each entity
in my relational database. You also encapsulate the business rules here,
such as validaing that required fields were entered, etc. This is also in
my case where my DCOM/SOAP calls will be made to.
Tier 3 is my data access layer. I will be writing a COM component that
would wrap ADO and handle all the DB access. This allows the system to be
flexible to changes in data access technology. I can take advantage of that
by changing it in one place. I am thinking of passing the data back to the
2nd tier using getrows or as a recordset by providing those two methods.
Tier 4 is the database. This is your SQL Server, Oracle, etc. You want to
take advantage of store procedures as much as possible.
My 2nd and 3rd tier will be Visual Basic components and yes they are all COM
components. That is the glue that makes all the magic work. You can learn the
basics of COM by reading a few high level
overview articles on MSDN. If you want a more indepth discussion of VB and
COM you can check out this tutorial,
http://www.develop.com/dm/dev_resources.asp#vbcom.
This conversation string was taken from the 15Seconds ASP Listserv on 4/18/01. If you have an ASP-related question or would like to share some of your knowledge with others, you may join the list by clicking here.
|
