代码可重用性 - App_Code或BIN或UserControls？

Question

我最近与另一位开发人员讨论了另一个论坛，主题是ASP.NET中的代码重用。所述方案是他需要在服务器正常运行时间内在生产服务器上频繁更新代码，这会导致会话重置为所有用户。他正避免将共享代码或类放入App_Code文件夹或预编译DLL到Bin文件夹中，因为任何更新也会刷新会话。

他提出的解决方案是将他的共享代码放入UserControls并在需要的地方引用它们。这使他只能更新UserControl文件，这些文件将在下次请求时动态重新编译，而不会强制重新启动会话。请注意，Usercontrols不具有任何UI，它们可能只包含一些业务逻辑。

我试图说服他反对这一点，因为这对我来说本身就是错误的 - 但我无法提供任何确凿的事实来支持我的说法，即这是一种非常糟糕的做事方式。我唯一能想到的是它违反了业务逻辑与UI分离的原则。我是否完全错误或者有没有具体的理由说明为什么不应该这样做？链接或示例会有所帮助。

注意：使用进程外会话状态目前不是一个选项，也无法决定计划的停机时间。此外，由于这是一个正在积极开发的网站，他们似乎还没有使用任何类型的专业部署模型。

提前致谢。

编辑：此外，如果有人能够明确说明会话在上述情况下重新开始的原因，将会很有帮助。

Answer 1

听起来主要的问题是他过于频繁地更新生产代码。除此之外，UserControls似乎是一个非常合理的放置业务逻辑的地方，特别是如果你有一个很好的命名约定或者可以将它们放在一个公共文件夹中。

Answer 2

请问，为什么进程外会话状态不是一个选项，真的吗？ 既然这个家伙似乎付出了太多的努力来解决这个“问题”，那么他会不会更好地寻找更好的解决方案？进程外会话状态是唯一的好解决方案。

Answer 3

这似乎是一种不寻常的方法，持久性会话是明显的答案。假设不使用持久会话的原因是合法的，有时你只需要使用任何工作。我要明确在源文件中记录用户控件的异常使用并使用它。

回答会话重置编辑的原因。在进程会话中，所有会话数据都作为应用程序的一部分存储在内存中。对网站的各种更改（例如web.config和其他我不记得的事情）会导致应用程序重新启动，消除应用程序中的所有当前状态。持久化SQL或进程外会话状态服务器将允许应用程序重置并丢失任何状态而不会影响会话数据。

Answer 4

我同意Dennis的观点，从inproc转移到状态服务器确实没有问题。不确定您的开发/部署平台是什么，但它们应该包括会话状态服务 - 启动它，更改您的web.config，问题就解决了。

Answer 5

这是一个解决常见问题的聪明（和丑陋）解决方案

主要问题是这种系统的架构;需要更新的代码可以放在他的Web应用程序之外的不同服务上，然后他的代码可以调用这些服务，并且可以在需要时更新服务而不影响Web应用程序

Answer 6

每个基地已经被覆盖，但我真的很讨厌这样的坏习惯。如果这个人不能简单地改为状态服务器来解决他所遇到的问题，那么他并不是真的值得帮助。如果他将他的课程放在项目的根文件夹中并独立编译，会发生什么？无论哪种方式，我认为这个人是一个糟糕的开发人员，不考虑可扩展性，而不是计划停机时间。我猜测的是他没有可用的开发环境。 Tsk tsk tsk。

作为您的问题的答案，正如其他人所说的那样，将代码放在用户控件中，然后将文档记录下来。