The ASPSmith Articles, ASPAlliance.com

• "Use pooled-process ASP pages and components" – Library and Medium/Low Isolation (1)
• "Be careful when passing object references" (1)
• "Better a single call to get/set many properties than many individual property Get and Set calls." (1)
• "Avoid delegation – it can quickly degrade performance, especially in a stateless environment" (1)
• "Pass arguments ByValue whenever possible. It is more efficient than ByRef." (1,2, 12)
• "Be careful when using the New keyword." (1, 2)
• "Adopt a Stateless Programming Model on the Server" – many reasons cited.(2)
• "Use ObjectControl_Activate and Deactivate Instead of Class_Initialize and Terminate" (2)
• "Acquire resources late, release them early" (2,5,7)
• "Set Unattended Execution on Your Project" (2)
• "Check "Retained in Memory" on Your Project" (2)
• "Do Not Declare Variables "As New" (2)
• "Store Your Application State in SQL Server" (2)
• "Close and Set Your ADO Objects to Nothing As Soon As Possible" (2)
• "Use OLE DB Providers Instead of ODBC Drivers" (2)
• "Use Stored Procedures Instead of Dynamic SQL Strings" (2)
• "Use OUTPUT Parameters on Stored Procedures for Single-Row Return Values" (2)
• "Use XML Strings or Recordsets to Send Data Between Layers… Transmit XML back and forth as a simple String, not as XML DOM objects or ADODB.Stream references. Remember to use ByVal whenever possible to avoid unnecessary back and forth marshalling, especially when dealing with large documents." (2)
• "Declare XML Functions and Parameters as Strings, not XML Objects" (2)
• "Partition Services Between ASP and Components… Isolate UI code from business logic. Place presentation components (those using Request and Response) in the same machine and/or process as the Web server." (2)
• "The MTS programming model discourages shared access to COM objects, preferring a model based on multiple COM objects sharing access to common state." (3)
• "Use MTS to share resources between users because it is typically more expensive to create a new resource than it is to simply reuse an existing one." (5)
• "Object lifetime—To be scalable, a COM+ application must pay close attention to the life span of objects. While an object exists, it is consuming resources." (6)
• "Use pooled-process ASP pages and components" – Library and Medium/Low Isolation (1)
• "Mistake 1: Instantiating Deep and Complex Object Hierarchies in a Middle Tier -- Development teams sometimes adopt complex sets of classes as part of a quest for object-oriented purity. In other cases, large numbers of simple objects are instantiated to model complex interactions through delegation. The practice of instantiating large numbers of objects and causing each to interact with the data store (to populate and persist itself) yields less scalable applications. Simply put, designing for the middle tier is not the same as designing for a traditional object-oriented fat-client application. The memory allocation associated with creating objects can be costly, and freeing memory can be even more so, because of the general practice of attempting to coalesce adjacent free blocks into larger blocks." (7)
• "Mistake 2: Performing Data-Centric Work in a Middle Tier" (7)
• "Mistake 3: Maintaining a Stateful Middle Tier" (7)
• "Because it can only maintain a limited amount of information, a stateful object is limited in how many callers it can have, whereas a stateless object does not usually suffer from this limitation." (11)
• "A noncached world is almost synonymous to a stateless world. Each function/method call to an object needs to have enough information passed to it so that it can complete its task without requesting more information from the caller or relying on state information." (11)