The ASP page, on the other hand, is really acting as the client tier and middle tier. We need a better way to approach building our applications. In the first place, we know that mixing presentation layer code with data access code is fundamentally a bad design choice. Second, the type of programmer that can maintain this code would need skills in both user interface and graphics stuff, which is usually handled by people more graphically inclined. Clearly there are two different skill sets required.
Components running in the middle tier are one alternative.
Using this approach, we can move the data access code and business logic out of our ASP page and into a component that is invoked from the ASP page. This is the more widely accepted approach today. Once we move our data access code into components separate from the ASP code, we have some choices about which technology we can use. Or we can take a similar approach, one that still leverages context and ASP but doesn't necessarily require Microsoft Transaction Server. The first approach involves making a reference to the Microsoft Transaction Server and ASP-type libraries in your component, and then utilizing the available context information to get what you need when the component is called from an ASP page.