ASP.Net编译模型的优点？
我正在与一位 PHP 开发人员合作，我们可以说，他对 .NET 不满意。他的抱怨包括必须为每个测试重建 Web 应用程序解决方案（尽管我指出，这通常仅在更改了 .cs 文件而不是接口 .aspx 文件时才需要），必须包含解决方案中的每个文件 我已经指出了编译
模型的许多优点，包括 RTTI（反射）、源代码完整性（源代码未部署到服务器，防止爱管闲事的 IT 人员现场修改它）飞），性能差异（尽管他坚持认为这是无效的，因为 PHP 现在是“编译”的），等等。 .NET 相对于 PHP 还有哪些其他优势？这可能会引发一场宗教辩论——上帝保佑，不——但我是 .NET 的忠实粉丝，以至于我几年前提出的一些问题看起来非常愚蠢，以至于我无法给出有效的回答。
他开发页面的方式似乎也存在显着差异。例如，声明一个代表页面一部分的类（例如，3 列布局中的特定列），而不是以更逻辑的方式分解代码并依赖 .aspx 来处理布局。让我感到奇怪的是，页面布局以任何方式都与类结构相关，超出了 aspx 页面的代码隐藏结构。
评论？
更新顺便说一句，这是一个老问题，但我觉得有必要更新几点：
优化这是一个大问题。编译提供了执行一些在 JIT 期间无法实际执行的优化的机会。
okw 提到的这篇文章明显有偏见，并且是由没有在 .NET 工作很长时间的人创建的，因此几乎不值得一读（尽管我读过）。它还提出了完全不正确的观点。
让 Mac 用户意识到 Windows 也有其一席之地几乎是不可能的。另一方面，我认识的大多数使用 Windows 的人都认为 Mac 可以做很多事情。大多数人甚至拥有一台。我们不使用它们来开发网站或嵌入式系统是有原因的。 （是的，我们的业务两者都密切相关。）
初恋变坏了……非常好的比喻。这可能很快就会在一次会议上从我嘴里说出来。
这种争论是没有用的。我不妨尝试说服英国人在路的正确一侧行驶。还有澳大利亚。还有香港。而且......你知道这是怎么回事。
干杯。
I'm working with a PHP developer who is, shall we say, unhappy with .NET. His complaints include having to rebuild the web application solution for every test (though I pointed out that this is usually only necessary if a .cs file has been changed, not interface .aspx files), having to include every file in the solution that is required to be deployed, etc.
I've pointed out a number of advantages of the compiled model including RTTI (reflection), source code integrity (source isn't deployed to the server, keeping meddlesome IT people from modifying it on-the-fly), performance differences (though he insists that this isn't valid since PHP is now "compiled"), etc. What are some other advantages of .NET over PHP? This may incite a religious debate - please God, no - but I'm such a fan of .NET that some of these questions which I asked years ago seem so silly that I can't articulate a valid response.
There also seem to be significant differences in the way in which he goes about developing a page. For instance, declaring a class which represents part of a page - say, a particular column in a 3-column layout - rather than breaking up the code in a more logical fashion and relying on the .aspx to handle layout. It strikes me as odd that page layout would, in any way, be tied to class structure beyond that of the code-behind for a aspx page.
Comments?
UPDATE BTW, this is an old question, but I felt it necessary to update with a few points:
Optimization This is a big one. Compilation provides the opportunity to perform some optimizations that aren't practical to perform during the JIT.
The article that o.k.w referred to is so obviously biased and created by someone that hasn't worked a significant time in .NET that it's hardly worth reading, (though I did). It also makes points that are entirely incorrect.
It's damn near impossible to make Mac people realize that Windows has its place. On the other hand, most Windows guys I know think that Macs are great for a lot of things. Most even own one. We don't use them for developing websites or embedded systems for a reason. (And, yes, our business involves both, intimately.)
First loves gone bad... excellent analogy. This will probably come out of my mouth in a meeting sometime soon.
This debate is useless. I may as well try and convince the UK to drive on the correct side of the road. And Australia. And Hong Kong. And... you see where this is going.
Cheers.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
我每天都使用这两种语言，两者都非常适合开发。如果不变得激烈和热情，就很难进入“编译与解释”的辩论，所以我认为我不会对此说什么。不过，以下是我更喜欢 .Net 的一些方面：
Visual Studio 与 Eclipse。
没有@includes和真正的命名空间。我想一直了解我的类型，而不是依赖奇怪的 hacky 自动加载例程。
API 的可发现性。 PHP 具有可怕的、不一致的 API 命名。
编译时间检查和代码分析
高级调试器和分析器
这实际上与他们使用的模型无关，而是只是工具本身的属性。我不建议尝试改变他的想法，甚至与他争论——他要么自己看到优势，要么不会，但把这些优势强加给他可能只会让事情花费更长的时间；）
I work with both languages daily, and both are great for development. It's hard to get into the "compiled vs. interpreted" debate without getting all flamey and zealous, so I don't think I'll say anything about that. However, here are some of things I prefer about .Net:
Visual Studio vs. Eclipse.
No @includes, and real namespaces. I want to know about my types all the time, and not rely on weird hacky autoloading routines.
API discoverability. PHP has horrible, inconsistent API naming.
Compile time checking and code analysis
Superior debuggers and profilers
This isn't really anything to do with the models they use though, it's just attributes of the tools themselves. I wouldn't suggest trying to change his mind or even arguing with him about it - he'll either see the advantages himself or he won't, but pushing them on him will probably just make it take longer ;)
据我了解（我自己在 PHP 方面工作不多），PHP 既强大又易于使用，并且真正适合较小、较简单的项目，特别是在业务逻辑主要由在数据库和网页之间移动内容组成的情况下。 ASP.NET 更适合更大、业务逻辑更密集的应用程序，其中编译时检查允许您更快地捕获错误。在编译时与运行时捕获错误可能会导致修复所需的时间存在一个数量级的差异。
在我工作的地方，我们使用 PHP 构建模型来向客户展示并让他们签署我们的想法，然后我们用 .NET 或 Java 等编译语言编写实际产品，因为这是我们需要维护的代码未来十年或更长时间。
From what I understand (not having worked much in PHP myself) PHP is both powerful and easy to use, and really shines on smaller, simpler projects, particularly where the business logic consists mostly of moving content between a database and a web page. ASP.NET lends itself better to larger, more business-logic-intensive applications, where the compile-time checks allow you to catch errors sooner. Catching an error at compile time versus run time can make an order of magnitude of difference in how much time it takes to fix.
Where I work, we use PHP to build mockups to show customers and get them to sign off on our ideas, and then we write the actual product in a compiled language like .NET or Java, since that's the code we'll need to maintain for the next decade or more.
主要问题是，如果存在适用于 .Net 的框架，则几乎可以使用 PHP 实现 .Net 的任何优势。我相信有 PHP MVC 框架。
不过，我要说的是关于 ASP.Net 的编译模型，了解所有隐藏代码中没有语法错误是非常有帮助的。 PHP 和 ASP Classic 没有这个。在一个拥有 400 多个页面的网站中，很难在一定程度上确定哪些页面有效，哪些无效。
The primary issue is that, almost any advantages you can come up with for .Net can be achieved with PHP if a framework exists for it. I believe there are PHP MVC frameworks.
However, I will say this about the compilation model for ASP.Net, it's extremely helpful to know that there are no syntactical errors in all your code behind code. PHP and ASP Classic didn't have this. In a site of 400+ pages it was difficult to know which ones were and weren't functional with a degree of certainty.