怎样用vb设计三层结构应用程序
各位高手，近日因公司要开发一个三层结构的应用程序，但是我以前没做过，现不知怎么办，所以特地请教各位，如何做，做这个需注意什么，有没人有这方面的例子，希望各位尽力帮忙，否则我就要......
我的E-mail:zhong_hj@163.net
问题点数：20、回复次数：19Top
1 楼july（沉船侧畔）回复于 2001-01-11 14:09:00 得分 0
ACTIVE DLL--->COM+ SERVIC-->VB/ASPTop
2 楼lou_df（ldf）回复于 2001-01-11 15:43:00 得分 0
用interdev开发（用vbscript)Top
3 楼zhong7810（）回复于 2001-01-11 16:56:00 得分 0
各位能不能详细点，最好给点例子，我已经把我的所有分都给出来了，请高手快帮忙Top
4 楼lxcc（）回复于 2001-01-11 23:59:00 得分 0
我以前用过vs里面的visual moudler
是三层的（data——》bussiness——》user），不知道是不是你说的
只是搭建基本模型
用熟练了，可以作项目经理了
Top
5 楼czh918（czh）回复于 2001-01-12 09:11:00 得分 0
html---asp---database
vb----dcom----database
如果想用vb的话，最好去读一读有关dcom的文章，在vb的例子中有很多dcom的例子Top
6 楼A_SOSO（SOSO）回复于 2001-01-12 09:35:00 得分 0
我也关注一下。
需要用到Com，Dcom的中间键。Top
7 楼zhong7810（）回复于 2001-01-12 09:48:00 得分 0
我也知道要用到com和dcom,但是各位可不可以具体点，指点一些到底怎么做Top
8 楼fmc（乡下表弟）回复于 2001-01-12 09:51:00 得分 0
没开发过，在我的感觉里，浏览器------》WEBSERVER（ASP，你自己开发的组件）——————》SQL SERVER，也应该是3层结构，这样的例子ASPHOUSES有下载，是琼海师范的管理系统。Top
9 楼amstar（阿门）回复于 2001-01-12 10:26:00 得分 0
关注Top
10 楼zhong7810（）回复于 2001-01-12 11:15:00 得分 0
到底有没高手，快帮忙，是不是我问的太深了？Top
11 楼zytang（zytang）回复于 2001-01-12 12:39:00 得分 0
关注Top
12 楼zytang（zytang）回复于 2001-01-12 14:46:00 得分 15
Three-Tier Application Development
Logical Three-Tier Model
The logical three-tier model divides an application into three logical components.
Figure 1. The three-tier model
Data services
These services join records and maintain database integrity—for example, constraints on valid values for a customer number and an enforced foreign-key relationship between the customer table and the orders table.
Business services
These services apply business rules and logic—for example, adding a customer order and checking a customer's credit availability.
Presentation services
These services establish the user interface and handle user input—for example, code to display available part numbers and orders for a selected customer.
When deploying an application, there are many ways you can arrange these three logical layers on physical machines. The following sections describe four physical implementations of the logical three-tier model:
Physical two-tier implementation with fat clients
Physical two-tier implementation with a fat server
Physical three-tier implementation
Internet implementation
Physical two-tier implementation with fat clients
A common method for deploying an application is a physical two-tier implementation with fat clients, where the business logic and presentation services all run on the client. In this implementation, the server acts only as a SQL Server database. Most applications written today using the Microsoft Visual Basic® or PowerBuilder programming systems are examples of this model.
Figure 2. Two-tier implementation (fat client)
A new option in this implementation is the ability to do OLE packaging of business rules for improved reuse. For example, using Visual Basic version 4.0 or later you can code business rules into an OLE object that you can call from another Visual Basic application. This allows you to physically separate business rules from your presentation logic in the code base. If both the user interface application and the business object run at the client, it is still a physical two-tier implementation. Separating the code, however, makes it easy to move to the physical three-tier implementation described later in this paper.
A primary advantage of this fat client implementation is that the tools that support it are powerful and well established. As of this writing, PowerBuilder is in its fifth major version, and Visual Basic is about to be released in its fifth major version. A disadvantage of this implementation is that deploying the business services at the client generally means more network traffic because the data has to be moved to the client to make the decisions coded in the business logic. On the other hand, the client computer is a good place to store "state" information associated with the user, such as the primary key of the record the user is currently viewing.
Physical two-tier implementation with a fat server
In a physical two-tier implementation with a fat server, business logic and presentation services are deployed from the server database. In this implementation, business logic is generally written as stored procedures and triggers within the database. For example, in the TPC-C benchmarks published for Microsoft SQL Server, the core transaction logic is coded as Transact–SQL stored procedures in the server. Many internally-developed corporate applications also make extensive use of stored procedure logic. Microsoft uses this implementation to handle internal business functions, such as customer information tracking.
Figure 3. Two-tier implementation (fat server)
The major new development in this implementation is the availability of a Transact–SQL debugger. This debugger is integrated into the Enterprise Editions of both Microsoft Visual C++® version 4.2 and later and Visual Basic version 5.0. This debugger makes it possible to step through Transact–SQL code, set breakpoints, and view local variables.
The major advantage of this fat server implementation is performance. The business logic runs in the same process space as the data access code and is tightly integrated into the data searching engine of SQL Server. This means data does not have to be moved or copied before it is operated on, which results in minimal network traffic and the fewest possible network roundtrips between client and server. The published TPC-C benchmarks from Microsoft Corporation and other major database vendors all use this implementation. In the SQL Server TPC-C implementation, each of the five measured transactions is performed in a single roundtrip from client to server because all of the logic of the transaction takes place in a Transact–SQL stored procedure.
The main disadvantage of this implementation is that it limits your choice of development tools. Stored procedures are written in the language supported by the database. SQL Server supports calls from the server to code written in languages other than Transact–SQL, but this option adds complexity and is generally not as efficient as the same functionality written in Transact–SQL.
Physical three-tier implementation
The physical three-tier implementation is one of many implementations of the logical three-tier model. Commonly referred to as the "three-tier model," it is often incorrectly thought of as the only physical implementation of the logical three-tier model. In this implementation, business logic runs in a separate process that can be configured to run on the same server or a different server from the server the database is running on. The key distinction of the physical three-tier implementation is that there is a cross-process boundary, if not a cross-computer boundary, between data services and business services, and another cross-process or cross-computer boundary between business services and presentation services. SAP's R/3 application suite is a physical three-tier implementation, as are many of the large financial and line-of-business packages from other vendors. Transaction processing monitor products such as Encina or Tuxedo also use this implementation.
Figure 4. Three-tier implementation
A major new option for using this implementation is Microsoft Transaction Server. Transaction Server can host business services written in any language that can produce OLE objects. Transaction Server manages the middle layer and provides many of the run-time services that would otherwise have to be built for a physical three-tier implementation. For example, Transaction Server provides a mechanism for reusing object instances among multiple users.
The physical three-tier implementation offers advantages of database independence. Most physical three-tier implementations access several databases. These applications generally treat databases as standardized SQL engines and make limited use of database-specific features.
Some variations of the physical three-tier implementations also offer language independence. Microsoft Transaction Server, for example, supports any language that can produce OLE/COM in-process objects, including Visual C++, Visual Basic, and Micro Focus COBOL. Any of these languages can be used to write business logic that is then hosted at run time by the Transaction Server. SAP's application, on the other hand, does not offer language independence—all application code developed in R/3 is written in their language called Advanced Business Application Programming (ABAP).
In some cases, the physical three-tier implementation is more scalable than other physical implementations. If the business logic code consumes a great deal of processor time or physical memory, it can be advantageous to locate those business processes on one or more servers separate from the database to avoid contention for resources. This potential scalability gain is offset by the additional cost of moving data across the network to the middle-tier servers, so it is not a win in all cases. Physical three-tier applications can also potentially access partitioned databases on multiple computers, giving an additional dimension of scalability. Partitioning the database, however, introduces enormous complexities into the application and is not a widespread practice in the industry today.
A disadvantage of the physical three-tier implementation is that it tends to require more management. Also, while the physical three-tier implementation can offer the capability to employ more physical computers on an application, it generally does not offer as compelling a price/performance ratio as an application whose logic is implemented in stored procedures.
Internet implementation
The Internet has introduced a new twist on the logical three-tier model: the ability to split the presentation services onto a browser client and a Web server. The Web server is actually responsible for formatting the pages that the user sees. The browser is responsible for displaying these pages and downloading additional code they may need. Between the Web server and the database, the choices remain the same for locating the business services logic.
A common Internet implementation is to run both business and presentation services at the Web server. In some products, the business logic can run in the Web server's process space, thus avoiding the overhead of crossing an additional process boundary. An example of a product that uses this implementation for database applications is Microsoft Internet Database Connector (IDC), which is part of the Microsoft Internet Information Server (IIS) in the Microsoft Windows NT® operating system. IDC connects to any ODBC data source, including SQL Server, retrieves data, and formats the data into an HTML page that is sent immediately to a browser client.
Figure 5. Internet implementation
There are many newly released products that support Internet implementations of database applications. For example, IIS version 3.0 allows developers to write business and presentation services in Visual Basic Script and includes the ability to load and invoke an OLE Automation object. Also, Microsoft ActiveX™ controls offer a way to run more of the presentation services and possibly the business services from the browser client. These extensions to Internet technologies give more flexibility for where you can deploy the logical three tiers of a database application written for browser clients.
One key advantage of Internet implementations is that anybody who has a browser client can access these applications. With little or no additional development effort, an application can be accessed simultaneously from the Microsoft Windows® operating system version 3.1, Windows 95, Windows NT, Apple® Macintosh®, OS/2, and UNIX clients. All of the client functionality required is provided by standard Web browsers. Ease of management is another key advantage of an Internet implementation. In an Internet application, an update to the Web server automatically updates all clients. Managing Web page code at a few servers is easier than managing application versions at many clients.
The basic Internet implementation today (for example, using IIS and IDC and putting business services at that Web server layer) is not a high volume online transaction processing (OLTP) solution. But it is important to note that the application implementations discussed in this paper can be mixed to combine their advantages. For example, an implementation that uses an application's business services in stored procedures and that handles presentation services at the Web server can be very efficient. In fact, Microsoft's latest TPC-C benchmarks use IIS to handle browser clients, as opposed to using the alternatives (see note below). So an Internet-style application can be used for high volume OLTP if business services are executed as stored procedures in the database.
Note The TPC-C benchmark requires fixed-function workstations (terminals) for end users. Most TPC-C benchmarks from other database vendors use Telnet-like servers running on UNIX to support these terminals. The IIS based on Windows NT has proven to be more cost-effective and more efficient at managing clients for SQL Server benchmarks.
Choosing an Implementation
Your application requirements will determine which physical implementation of the logical three-tier model you choose. The key requirements to consider are:
Performance and scalability
If your throughput requirements are high and optimum price/performance is the goal, an implementation that uses business logic in stored procedures may be called for.
If your business services are resource intensive and the ability to apply many servers to the application is the goal, a physical three-tier implementation may be best.
On the other hand, PC hardware has become so powerful and cost effective that your application performance requirements can be satisfied easily by any one of these implementations.
Client platform and access
If a variety of client platforms must have access to your application, an Internet implementation is compelling.
Developer skills, especially skills in a particular language.
If you have developer skills or existing code in a particular language, the cost of choosing an implementation supported by that language is significantly lower.
Administration
Different implementations require different administrative overhead.
Database and/or tool independence
Some implementations require an application to be oriented to a specific database or language.
All of these considerations affect the decision of how to physically implement a three-tier application. There is no one correct answer—the best course of action is to thoroughly understand the alternatives and the trade-offs before choosing an implementation.
When you choose a development tool and decide how to implement the logical three-tier model, you must also choose the interface by which your client application will communicate with SQL Server. The best interface to use depends on the development language and the type of application under development. The choices fall into three categories:
Call-level interfaces
Object interfaces
Embedded SQL
--------------------------------------------------------------------------------
Send feedback on this article. Find support options.
© 2000 Microsoft Corporation. All rights reserved. Terms of use.
Top
13 楼A_SOSO（SOSO）回复于 2001-01-12 18:04:00 得分 0
关注Top
14 楼qlming（心语）回复于 2001-01-13 14:10:00 得分 0
是不是“客户端程序---服务端服务程序----数据”这样的模式？Top
15 楼xiaohei（）回复于 2001-01-14 13:18:00 得分 5
三层：表现层、业务逻辑层、数据服务层。这就是windows DNA.
Windows DNA的核心就是通过COM（Component Object Model，组件对象模型）将网络和客户/服务开发模型集成起来。Windows DNA的服务通过COM 为应用程序的使用提供了一种统一的方式。这些服务包括组件管理、动态HTML、网络浏览器以及服务器、脚本编辑、事物处理、消息队列处理、安全性、数据库、数据存储、系统管理和用户界面。
Top
16 楼cloud_soft（cloud）回复于 2001-01-14 13:30:00 得分 0
guanzhuTop
17 楼zhong7810（）回复于 2001-01-15 08:31:00 得分 0
回qlming:我现在要做的正是“客户端程序---服务端服务程序----数据”模式，你是否有这方面的经验，能否给个例子，fast!!!!!!!!!!!!!!!!Top
18 楼zhong7810（）回复于 2001-01-16 11:19:00 得分 0
唉，看来我只有等待失业了，这么多人，这么久都没有人给我说详细的答复!可悲！！！！Top
19 楼lou_df（ldf）回复于 2001-02-12 10:21:00 得分 0
用interdev开发服务器端asp程序（business层），访问数据库（data层）。用户层用浏览器界面。Top
相关问题
关键词
得分解答快速导航
相关链接
广告也精彩
反馈
