是MVC至code asp.net应用程序的最佳方法是什么？ [英] Is MVC the best way to code asp.net applications?

问题描述

更新：我知道有没有做的一切最佳方法。对不起，我不是说马上。在数据访问教程的背景下，如果你不得不做他该教程中所做的项目，你会做什么，他做了或者将使用使用MVC框架，如果你不得不选择其中之一吗？

update: I know there is no one best way to do everything. Sorry for not saying that right off. In the context of the data-access tutorials, if you had to do the project he did in that tutorial, would you do what he did or would use use MVC, if you had to choose one of them?

更新：是MVC编程asp.net应用程序的更合适的方式，而不是在这里找到教程：

Update: Is MVC the more appropriate way to program asp.net applications, instead of the tutorials found here:

http://www.asp.net/Learn/data-access/

原文：

我问，因为我最初了解MVC Java应用程序，那么之类的东西回报率，Django的和。这些其他项目和企业说话好像MVC已经存在了很长一段时间，从我发现它了。那么，微软开始将MVC到.NET框架。

I ask, because I initially learned about MVC with Java applications, then things like RoR, and Django. These other projects and companies spoke as if MVC had been around for a very long time, and from what I found out it had. Then Microsoft started putting MVC into the .net framework.

我问，因为我不知道如何设计的东西非常好，认为我做得很好仿效什么在asp.net网站与斯科特·米切尔教程。我认为，在一个BLL创建抽象层是要走的路，直到我发现了MVC和现在asp.net的MVC。

I ask because I don't know how to design things very well and thought I was doing well to emulate what's on the asp.net site with Scott Mitchell's tutorial. I thought that creating abstract layers in a BLL was the way to go until I found out about MVC and now asp.net's MVC.

我真的不知道正确的方法是做的事情。我只是创建我需要什么，但我不禁觉得我失去了一些东西。

I honestly don't know what the "right" way is to do things. I just create what I need, but I can't help feel like I am missing something.

时的MVC开始在大型项目做事情的正确方法，特别是我的意思是MVC和ASP.NET，但也可以同样意味着PHP和其MVC框架之一。

Is MVC the correct way to start doing things in large projects, specifically I mean MVC and ASP.NET, but could just as well mean PHP and one of their MVC frameworks.

我想定居在做的事情......现在反正的标准方式。

I'd like to settle on a standard way of doing things...for now anyway.

和，出于好奇，为什么微软现在才开始做MVC？

And, out of curiosity, why did Microsoft only now start doing MVC?

更新：是MVC比目前的教程asp.net设置好

UPDATE: Is MVC better than the current tutorial set on asp.net?

我指的是他在那里为抽象创建BLL斯科特·米切尔教程。或者是，一个LINQ问题为好。我应该说我明白保持逻辑和presentation独立的，但不确定做到这一点的最好办法的必要性。我用的是asp.net教程。它工作得很好。后来我发现了世界其他地方，因为我看到了也无妨，使用MVC。那么微软开始开发MVC，所以我其他的方法似乎过时和错误的方式做事情。

I'm referring to the Scott Mitchell tutorials where he creates the BLL for abstraction. Or is that a linq question as well. I should have said that I understand the need for keeping logic and presentation separate but unsure the best way to do it. I was using the asp.net tutorials. It worked fine. Then I found out the rest of the world, as I saw it anyway, was using MVC. Then Microsoft started developing MVC, so to me the other method seems obsolete and the wrong way to do things.

推荐答案

没有，这不是做事情的唯一最佳途径。

No, it's not the only best way to do things.

MVC是只是一个设计图案。所有的设计模式的目标是简单。所以只要它使你的设计更简单，去用它。如果它使事情更复杂的针对特定的应用程序，尝试不同的方法。

MVC is just a design pattern. The goal of all design patterns is simplicity. So as long as it makes your design simpler, go with it. If it makes things more complex for your specific application, try a different approach.

不幸的是，有些人认为，如果他们看到一个模式，他们应该使用它。这是不是真的。设计模式没有本质上使应用程序更好。他们不是结束。他们是达到目的的一种手段（这是简单）。所以，你应该使用它们只有当他们是值得的。

Unfortunately, some people think if they see a pattern, they should use it. It's just not true. Design patterns don't inherently make your application better. They are not an end. They are a means to an end (which is simplicity). So you should use them only if they are worth it.

在我看来，过度架构的东西没有一个很好的理由比写code没有任何具体的设计更糟。

In my opinion, over-architecting things without a good reason is worse than writing code without any specific design.

编辑：关于ASP.NET MVC：我对ASP.NET Web表单负个人偏见。 MVC之前，我做了最先进的项目动态方面通过编写定制的处理器拥有比HTML的细粒度控制。 Web窗体使Web开发很容易，但他们有特别有两件事情是好的，但有时是有问题的。其中第一个是的ViewState ，第二个是复杂的的WebControl 架构。不要误会我的意思。这些都是ASP.NET的辉煌的迹象。我还没有看到Web开发一个单一的平台，ASP.NET Web窗体一样方便，这是不仅是因为它要求 ViewState的大的WebControl 支持。然而，在一些项目中，你想有上呈现HTML（特别是当你有一些客户端逻辑）precise控制。你也想​​使服务器端code在大型项目维护。在这些地区，ASP.NET MVC真正的亮点。但我认为ASP.NET Web窗体将保持一个伟大的技术，它是更为适用。毕竟，正如我所说的关于一般的设计模式，您应该仔细评估你的设计，看看哪一个更适合您的需求。

Regarding ASP.NET MVC: I have a negative personal bias toward ASP.NET Web forms. Before MVC, I did most of the dynamic aspects of advanced projects by writing custom handlers to have fine grained control over the HTML. Web Forms make Web development very easy but they have particularly a couple things that are good but sometimes are problematic. The first of which is ViewState and the second is complex WebControl architecture. Don't get me wrong. Those are signs of brilliance of ASP.NET. I haven't seen a single platform for Web development as easy as ASP.NET Web Forms and this is only because of great WebControl support which requires ViewState. However, in some projects, you want to have precise control on rendered HTML (specially when you have some client-side logic). You also want to make server side code maintainable in large projects. In those areas, ASP.NET MVC really shines. But I think ASP.NET Web Forms will remain a great technology where it's more applicable. After all, as I said regarding design patterns in general, you should carefully evaluate your design to see which one better fits your needs.

具体来说，有关数据访问，MVC通常需要更多的code比Web窗体同行。对于presenting表格数据（即GridView控件在哪里适用），我认为ASP.NET Web窗体是要完成的事情更简单的方法。但是，大多数数据驱动的Web应用程序不只是在数据库中直接操作的表。他们有复杂的布局。计算器就是一个很好的例子。这当然是数据驱动的，但ASP.NET MVC更适合它。

Specifically, about data access, MVC usually requires more code than Web Forms counterparts. For presenting tabular data (i.e where GridView is applicable), I think ASP.NET Web Forms is the easier way to accomplish things. However, most data driven Web apps are not just manipulating a table directly in a database. They have complex layout. StackOverflow is a great example of this. It is certainly data driven, but ASP.NET MVC better suits it.

这篇关于是MVC至code asp.net应用程序的最佳方法是什么？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！