|
bsp;
分割服务
建议
将表达、业务和数据服务分离。业务组件应该实施业务规则。业务组件不应包含数据访问技术。那是数据层组件的任务。业务组件不应包含对 ASP 对象的引用。
ASP 提供表达服务。引用 ASP 的对象应该呈现为 HTML。这些对象能够依次调用对 MTS/COM+ 注册的业务对象。
为什么
将应用程序分割为单独的和截然不同的服务，有以下好处：
更便于组件的重用
支持 Windows DNA model（英文）
更好地孤立疑难问题
更灵活的部署选项（去掉服务的耦合允许在多台计算机上分布应用程序）
常见的陷阱
有一种我们称为“瑞士军刀”组件的常见问题。 该“瑞士军”组件将所有服务合成一体 （就像有螺丝锥、牙签等 17 种工具的小瑞士军刀）。 把不相关的服务组合到一个组件中， 使该组件很难使用、理解和维护。
容易掉入的另一个陷阱是从业务组件中引用 ASP。使 ASP 和业务逻辑耦合（通过使用 请求或响应对象，或在其内部构建 HTML），不仅限制不同的客户机重用您的组件，而且限制了横向的可伸缩性。引用 ASP 内置对象的对象应该与 Web 服务器在同一框围中。理想情况下，由于横向可伸缩性，业务组件可以分布在不同的框围中。可以直接在 ASP 脚本中提供表达服务，也可以建立呈现引用 ASP 内置对象的组件的 HTML，并将这些组件保持在 IIS 框围中。
详细信息
成功的设计模型可用作处理公共业务问题的模型。例如，处理“创建读更新删除(CRUD)” 操作的模型，可帮助您将应用程序分为几个截然不同的逻辑服务，即表达、业务规则和数据访问。
请参阅下文以获得更多的设计模型具体示例，可以在您自己的应用程序中模仿它：
Scalable Design Patterns（英文）
Simplify MTS Apps with a Design Pattern（英文）
FMStocks Application: Start Here（英文）
线程模型
建议
选择组件的范围还是选择组件的线程模型，哪种方法优先？两种方法都要考虑线程分支，除非决定在页面范围内使用“单元”或“双重”模型组件。（如果 Visual Basic 程序员不知道组件是哪种线程模型，则总是“单元”。）
如果需要在“应用程序”或“会话”中存储对象，则需要使用标记为“双重”的组件并聚集“自由线程编组程序 (FTM)”。
不要使用“单线程”组件并避免使用来自 ASP 的“自由线程”组件。
注意： 如果不小心， Visual Basic 可产生“单线程”组件。请确保在项目属性页的常规选项卡上将线程模型设置为单元线程。还要注意在相同选项卡上选定无人值守执行和保留在内存中选项。
为什么
如果您使用的是 Visual Basic，它是一种“傻瓜”开发环境。 Visual Basic 仅限于使用“单元”模型。假如 Visual Basic“单元”模型对象执行得非常良好，我不想对页面范围上的限制考虑太多。 Fitch 和 Mathers Stock 2000 破坏了对性能的任何预先想法。另外，由 ASP、SQL 和 Visual Basic 构建的许多现有网站，无时不刻都在证明页面范围的“单元”模型组件是可伸缩和执行的。
如果在标记为“双重”的组件上聚集 FTM，则可以不用任何编组或线程切换，便能在线程之间调用。如果标记为“双重”的组件没有聚集 FTM，ASP 将其视为“单元”线程对象 — 就像 Visual Basic 组件一样。请记住，如果计划利用“COM+ 对象池”，则不要聚集 FTM。 有关“对象池”的规则，请参阅“平台 SDK”文档。
“单线程”和“自由线程”组件运行在“系统”安全环境下。更糟的是，“单线程”组件会导上一页 [1] [2] [3] [4] [5] [6] [7] [8] 下一页 |
|
|
|
|
|
|
|
