Passing ASP Objects to VB COM Components

Results 1 to 2 of 2

Thread: Passing ASP Objects to VB COM Components

  1. #1
    Join Date
    Dec 1969

    Default Passing ASP Objects to VB COM Components

    I am trying to modularize the design of an ASP website and move a lot of the logic into VB COM components. I know that I can successfully pass a reference to the ASP objects (Application, Server, Request) to my VB COM methods. My question is: Is this a good thing to do? Are there any performance impacts? This will be a production environment, so performance is a big concern.<BR>

  2. #2
    Join Date
    Dec 1969

    Default RE: Passing ASP Objects to VB COM Components

    Hope this may help you out..<BR>(Or search on msdn)<BR>Courtesy : <BR><BR>I showed you two examples of using MTS components written with Visual Basic in an ASP-based application. In both cases, Visual Basic was used to write the data access layer and ASP was used to define the presentation layer. That is an important characteristic of a three-tier system. The presentation logic never mingles with the data access code. What changed between the first and second examples is where the business logic was defined—<BR>what it means to submit a sales order. In the first example, this business logic was defined in the CBroker class of the Visual Basic-based DLL. In the second example it was defined in ASP code. Both examples used the MTS runtime environment to guarantee the ACID requirements of their transactions. The ASP code for these examples can be seen in SubmitOrder1.asp and SubmitOrder2.asp in the source code.<BR>&#060;/msj/images/dingbats/indent.gif&#062; The fact that IIS/MTS integration allows you to create transactional ASP pages doesn&#039;t mean that you have to use them. You might elect to maintain your business logic in a DLL as opposed to ASP code. There are a few reasons you might do this. Using classes available in Visual Basic or C++ will make it easier to maintain and extend your business logic with much better type checking and debugging capabilities. Compiled DLLs give you much better versioning control. Furthermore, you can use these DLLs from standard COM client applications as well as ASP clients.<BR>&#060;/msj/images/dingbats/indent.gif&#062; You might choose to maintain your business logic in ASP because of the advantages of a compile-free development environment. You might find it easier to make revisions without having to rebuild and replace a DLL. Now that you&#039;ve seen the issues you&#039;ll need to consider, you&#039;re ready to make that choice.<BR><BR>In this article, I&#039;ll discuss building MTS components with Visual Basic 5.0 for deployment within an ASP-based application. There are several benefits to moving your business logic and data access code out of your ASP pages and into a COM-based DLL. First, ASP is great for small apps, but it becomes increasingly difficult to manage an application that contains thousands of lines of code. Using a class-based language like Visual Basic, Java, or C++ will offer much higher levels of encapsulation and code reuse. Second, today&#039;s multitier designs encourage the use of business objects to separate the user interface code from the data access code. One of the benefits of this separation is that it eliminates the need for SQL in your ASP code. Third, COM-based DLLs created with Visual Basic can take full advantage of the integration between Internet Information Server (IIS) and the MTS runtime environment. Using MTS components in an ASP-based application gives you an infrastructure for building a reliable OLTP system. <BR><BR>Regards,<BR>

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts