.Net 实现答案 - 爱码网

【问题标题】：.Net implementations.Net 实现
【发布时间】：2008-12-31 22:11:25
【问题描述】：

我曾在两家以两种不同方式实施 ASP.Net 的公司工作过。我倾向于倾向于 A，但我目前的工作遵循 B（更典型）的方法。我想知道哪个是最好的，还有，这些实现是否有正式的名称？

A) 没有构建项目或解决方案。我们只是将 Visual Studio 指向一个目录并开始构建页面（我们有内联 aspx 页面和 aspx/code-behind 页面的组合）。我们只是将文件推送到服务器上，就是这样。如果我们需要任何第三方功能，所有类和服务都位于 App_Code 目录或 Bin 中。我们从未在 .Net 中使用过“构建”功能，而且大部分内容都是 JIT 编译的。调试是通过老式的 Response.Write() 方式完成的。

B) 创建了一个项目。有 Resx 文件、sln 文件和项目文件等。我确信大多数 .Net 开发人员都习惯了该项目的编译、构建和调试方式。一切都与 VS IDE 密切相关，尝试在 Visual Studio 的另一个副本中打开“项目”需要与发起项目的人相同的目录/本地主机设置。

听听曾在这两种实施方式中工作过的人以及他们在这两种实施方式中发现的好处会很有趣。

我问的原因是，我想引导我目前的开发团队更倾向于 A 实现，并删除所有这些将你锁定在 VS 中的外围文件和配置，但我也愿意来听听喝 Microsoft Kool-Aid 的好处。

【问题讨论】：

您能说明为什么您的方式 (A) 更好吗？在 MS Stack 上编程时，与 MS 工具绑定有什么问题？
WEBDTC 谈到了我喜欢 A 的原因之一。不用每次上线都编译真是太好了。我们最近遇到了一个错误，该错误被隔离到生产环境中并且易于调试，对我们在各个地方的代码进行小幅调整。使用推送/编译模型来做这件事会是一场噩梦。
我喜欢 A 的一个新例子出现在我的生活中：我找到了一个正在使用其他 webdev 团队的客户。由于其他 webdev 团队正在被替换为.. 嗯.. 我，我被困在一个位置，我目前只能访问构建而不是工作文件。

标签： asp.net .net visual-studio

【解决方案1】：

我出于充分的理由使用了这两种方法，但坦率地说，B) 比 A) 更可取。

如果您正在开发代码并将其交给开发能力有限的客户，那么 A)（我们将其称为网站项目）可能是最好的方法，同时保持其他一切简单尽可能。

但是，如果您正在开发一个只有您的公司会处理代码的应用程序，那么您真的想学习如何使用 B) 方法（我们将其称为 Web 应用程序 probject）。

Web 应用程序项目可以更好地控制项目中的内容、实际发布的内容，并且至关重要的是可以带来更好的测试。我建议你接受这种方法，而不是试图说服你的同事远离网络应用程序。避免在 App_Code 和代码隐藏文件中发布代码。构建和发布程序集，添加到解决方案库项目中。

【讨论】：

有什么理由不使用代码隐藏？我一直觉得这很方便。
现在后面的代码很棒。我认为使用单个页面或代码之间没有太大区别，因此它更像是个人喜好。我认为整个项目应该遵循相同的设置。
我没有说不要使用代码隐藏我说不要发布代码隐藏。但是，我也意味着应该将尽可能多的应用程序逻辑推送到库类中。这是为了更好地测试。

【解决方案2】：

我宁愿被“锁定”在 Visual Studio 中，也不愿失去调试器。你们多久需要在 VS 之外进行开发？我猜永远不会。您已经在使用 MS 产品，请按照预期的方式使用它。

【讨论】：

@Arjan Einbu，我认为您需要重新阅读问题/答案。如果没有 Visual Studio，您将失去调试器。这就是他要表达的观点。
抱歉，漏掉了那句话。不过，当他可以在 A 和 B 中以相同的方式进行调试时，他为什么会在调试方式上有所不同...
A 和 B 方法都允许您使用调试器，并且 A 和 B 方法都按照预期使用方式使用 VS.net。关于调试的问题评论与方法A或B无关。
啊，好吧。我将 OP 关于使用 Response.Write() 的评论作为他无法使用调试器的指示。我不是网络人，所以我不知道。
实际上，当向可能希望进一步定制的客户发布代码时，能够访问 VS 之外的源代码是很有用的。两种模型都有其用途。

【解决方案3】：

如果您使用的是 ASP .NET，那么您已经“喝了 Microsoft Kool-Aid”，或者至少喝了不少。

使用 A，您主要将 Visual Studio 用作美化的文本编辑器，所有调试、组织和其他工作都是手动完成的。

使用 B，您可以使用 Visual Studio 中的所有调试和编辑功能。不利的一面是，Visual Studio 有自己的方式来做一些最初强加给你的事情。尽管通过一些努力，您可以修改项目设置以按照您的意愿行事。

在任何情况下，您都必须比较您获得的与失去的。在从 A 到 B 的情况下，您失去了一点灵活性，但获得了大量的调试能力。

【讨论】：

【解决方案4】：

几天前看到this question and answers...

【讨论】：

【解决方案5】：

我更喜欢方法 A。我喜欢让事情尽可能简单。使用方法 A，我知道网站需要目录中的所有内容。使用 B 可以从项目中排除文件，但目录中仍然有这些文件。如果您从 Windows 资源管理器中查看该站点，我认为这会令人困惑。

使用 A 可以很容易地为页面部署一个小修复。使用 B 您需要重新编译项目并重新部署。与此相关的 A 允许您使用任何编辑器进行更改和部署。 B 要求你使用 VS.net。

B 引入了更多的依赖性和复杂性，这可能导致更多与站点代码无关的问题。

A 可以与任何源代码控制配合使用。对于 B，我在项目和解决方案文件方面遇到了问题。 B 还将网站不需要的文件添加到项目中。

A 和 B 都可以使用 VS.net 进行调试。无需将 response.write 与 A 一起使用。

【讨论】：

【解决方案6】：

我也同时使用这两种方法。如果您像安东尼所说的那样完成后其他人将为该站点提供服务，那么选项 A 确实是要走的路。选项 b 使开发变得更加容易，对我个人而言，我认为选项 B 可以提高工作效率。

【讨论】：

【解决方案7】：

你对 B) 的工作方式做出了错误的断言：

尝试在 Visual Studio 的另一个副本中打开“项目”需要与发起该项目的人相同的目录/本地主机设置。

这并不完全正确。重要的设置应该包含在解决方案中，虽然您确实需要作为项目一部分的相同文件夹结构，而不是您暗示的繁重负担。在开发人员之间移动项目通常很容易。至少，不会比类似范围的桌面应用程序更难。

如果您使用源代码管理，则尤其如此。只需检查项目，您担心的任何文件夹结构都应随附。

【讨论】：

【解决方案8】：

“一切都与 VS IDE 密切相关，尝试在另一个 Visual Studio 副本中打开“项目”需要与发起项目的人相同的目录/本地主机设置”

不是根据我的经验。 Web 项目下的目录需要相同，但对于任何 Web 应用程序都是如此。如果您正在谈论 3rd 方引用（例如 dll），那么您可以创建一个名为“References”的文件夹并将它们放入其中。这样，每个人都将指向相同的文件夹（就本地项目而言……您是否将项目存储在与其他人不同的名称目录中并不重要）。

至于 localhost 设置...我不确定你在说什么。在 Web 服务器设置方面，方法 A 与方法 B 有何不同？

【讨论】：