在构建企业解决方案时,可以安全地加入 ASP.NET MVC 潮流吗?

发布于 2024-07-17 20:08:43 字数 1295 浏览 2 评论 0原文

在我被指出其中一个“VS”之前。 像下面这样的问题...

...请让我声明我并不是在寻找比较。

我需要解决的一些问题包括:

  1. 做疯狂的 UI(例如,在线构建 BOM 树的 UI)的学习曲线是否陡峭? 很多发布问题的人似乎都遇到了某些 UI 要求或其他让我担心的问题。 技术是否足够成熟来满足这些类型的要求?
  2. 是否有一个相当发达的社区?在线文学的可用性如何? 您可以获得大量有关 WebForms 的文献。
  3. 开发它的时间与构建传统的企业 WebForms 站点相当还是更少?
  4. 让整个开发团队熟悉(如果不是迷恋)WebForms 并精通 ASP.NET MVC 需要多长时间?

我认为事实是 StackOverflow 是类似 Google 的产品,而 ASP.NET MVC 可能非常适合这一点。 但我一直在开发贵公司的应用程序类别的软件。

替代文本 http://stuffthathappens.com/blog/wp- content/uploads/2008/03/simplicity.png

因此,如果某些事情无法完成或必须被黑客入侵,那么尝试一下可能会付出高昂的代价。 希望能听到那些已经冒险的人的声音。

谢谢。

Before I get pointed to one of those 'VS.' questions like below...

... please let me state that I'm not looking for a comparison.

Some of my concerns that I need answers for include:

  1. Is the learning curve for doing crazy UIs (e.g. having UI for building a BOM tree online) steep? Lots of people posting questions seem to be having problems with some UI requirement or another which has me worried. Is the technology mature enough to handle those type of requirements?
  2. Is there a pretty well developed community and how available is online literature? You can get tons of literature for WebForms.
  3. Would the time to develop it be comparable or less to building a traditional enterprise WebForms site?
  4. How long would it take to get a whole team of developers comfortable (if not enamored) with WebForms to become well versed in ASP.NET MVC?

The truth of it I think is that StackOverflow is Google-like product and ASP.NET MVC might be great for that. But I'm stuck developing software in the Your company's app category.

alt text http://stuffthathappens.com/blog/wp-content/uploads/2008/03/simplicity.png

So taking a plunge could prove very costly later on if something can't be done or it has to be hacked. Hope to hear from those that have taken the plunge.

Thanks.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

下雨或天晴 2024-07-24 20:08:43

大约 3 个月前,我被告知我需要开发一个企业 Web 应用程序(实际上是一系列小型 Web 应用程序),但我可以选择我想要的任何技术。

由于我对 VS/C#/.Net 最熟悉,因此面临的困境是选择 ASP.NET WebForms 还是 ASP.NET MVC2 —— 与您不同,我唯一的背景是 Windows 窗体 (WinForms) 和一点 WPF。 所以我必须研究(并尝试)WebForms 和 MVC。

就像你一样,我意识到我的应用程序既不像谷歌也不像苹果,而是你的沼泽标准公司应用程序,有数千个按钮和框等。WebForms 似乎是部署最快的,但很难测试,也很难长期维持。 MVC 似乎有一个更陡峭的学习曲线,但一旦建立,测试和维护将变得轻而易举。

我只摆弄了 WebForms 一周,所以我无法对其进行真正的评论。 但 MVC 绝对符合我的预期。

是的,这是一个陡峭的学习曲线。 对我来说新的概念:

  • 模型-视图-控制器(MVC)
  • 关注点分离(SoC)
  • 模型绑定
  • 单元测试和测试驱动设计(TDD)
  • 模拟和存根
  • 依赖注入(DI)

对我帮助最大的书是:

  • < a href="https://rads.stackoverflow.com/amzn/click/com/1430228865" rel="nofollow noreferrer">Sanderson 的 Pro ASP.NET MVC2(MVC、模型绑定、DI、TDD)
  • Osherove 的单元测试艺术(TDD、Mocking、Stubbing、DI)

我还必须温习 HTML、CSS 和 Javascript。

总的来说,一开始似乎有相当多的启动工作,但维护和扩展现有应用程序相当轻松。 每当我被要求做出改变时,这都相当容易,而且我通常能够按时甚至有时提前交付。

在理想的世界中,编写 MVC 应用程序将由 2 个人进行。 一个人编写核心代码,另一个人编写 UI 和视图(HTML、CSS、Javascript)。尽管您完全可以自己完成这一切。 (这就是我现在正在做的事情......)

不过,我在企业中部署时遇到了一些问题。 在内部,我的公司运行的是 Windows Server 2003 和 IIS6。 不幸的是,当使用虚拟路径时,我们无法让应用程序在 IIS6 上正确部署。 (CSS 文件中的所有引用均已损坏。)如果您计划部署 MVC,我建议使用 IIS7 或更高版本。 MVC 据说可以在 IIS6 上运行,但要求您的 IT 部门愿意弄清楚如何让它工作。

编辑:我刚刚意识到我从未直接回答过你的问题。 这里是:

  1. 我的个人经验表明,是的,构建良好的模型和 UI 的学习曲线很陡峭,但我并不是真正的 Web 开发人员,所以我一直在克服这个障碍。 好消息是 MVC 技术相当成熟。

  2. 是的,社区非常发达并且不断发展。 您将从 StackOverflow 以及 MS 的 ASP.NET MVC 子论坛中得到很多好的答案。

  3. 我没有编写 WebForms 的个人经验,但我编写过很多 WinForms 应用程序,我觉得这花了我大约 10 分钟的时间。 构建此 MVC 应用程序的时间延长了 3 倍。 最初的投资是一笔巨大的开支,但定期维护和改进似乎来得更快,尤其是随着应用程序的发展……由于你们似乎有一个程序员团队,所以对你们来说可能会来得更快,因为你们可能可以分开学习/工作量。

  4. 再说一次,我之前没有使用 WebForms 的经验,但我可以告诉你的是,当我学习 ASP.NET MVC 时,有时我很难理解发生了什么,因为我之前没有 ASP.NET 背景。 (示例:成员资格和角色提供者 - 我最近不得不编写自己的代码。男孩真是太有趣了...)从好的方面来说,我没有任何“旧的做事方式”(又名 WebForms)需要忘记任何一个。 如果您有一个热衷于 PostBack / CodeBehind 的团队,您可以打赌 MVC 一开始会显得非常奇怪。 但希望您的团队能够看到 MVC 带来的优势并充分接受它。

哦,应该注意的是,您可以混合 MVC 和 WebForms。 这不是一个全有或全无的提议。 不过,如果我处于您的立场,我会尝试尽可能多地采用 MVC,并且仅在明显更有意义的情况下使用 WebForms。

好的,我希望这有帮助......:-)

About 3 months ago, I was told that I needed to develop an enterprise web-app (well, a series of small web-apps actually), but that I could choose whatever technology I wanted.

Since I'm most comfortable with VS/C#/.Net, the dilemma was whether to choose ASP.NET WebForms or ASP.NET MVC2 -- Unlike you, my only background was with Windows Forms (WinForms) and a little WPF. So I had to research (and try-out) both WebForms and MVC.

Just like you, I realized that my app would be neither Google nor Apple like, but your bog standard company app with thousands of buttons and boxes, etc. WebForms seemed like it would be the fastest to deploy, but hard to test and hard to maintain on a long-term basis. MVC seemed to have a much steeper learning curve, but once established, testing and maintenance would be a breeze.

I only fiddled with WebForms for a week, so I can't really comment on it. But MVC is definitely everything I was expecting it to be.

Yes, it's a steep learning curve. Concepts that were new to me:

  • Model-View-Controller (MVC)
  • Separation of Concerns (SoC)
  • Model Binding
  • Unit Testing and Test Driven Design (TDD)
  • Mocking and Stubbing
  • Dependency Injection (DI)

The books that helped me the most were:

I also had to brush up on my HTML, CSS, and Javascript.

Overall, there seems to be a fair amount of ramp-up work in the beginning, but maintaining and extending the existing application has been pretty painless. Whenever I've been asked to make changes, it's been fairly easy and I've typically been able to deliver on-time or even sometimes ahead of schedule.

In an ideal world, writing an MVC app would happen with 2 people. One person writing the core code and a second person writing the UI and the Views (HTML, CSS, Javascript.) Although it's entirely possible to do it all by yourself. (which is what I'm doing right now...)

I have run into some hitches deploying in the Enterprise, though. Internally, my company is running Windows Server 2003 and IIS6. Unfortunately, we have been unable to get the app to deploy properly on IIS6 when using Virtual Pathing. (All the references to and in the CSS files are broken.) If you plan on deploying MVC, I would recommend using IIS7 or higher. MVC supposedly works on IIS6, but requires that your IT department be willing to figure out how to get it to work.

Edit: I just realized I never directly answered your questions. Here goes:

  1. My personal experience has said, that, yes, the learning curve is steep for building good Models and UIs, but I'm not really a web-developer so I've been working with that handicap. The good news is that the MVC technology is pretty mature.

  2. Yes, the community is pretty well developed and growing. You'll get a lot of good answers from StackOverflow as well as MS's ASP.NET MVC sub-forum.

  3. I have no personal experience coding WebForms, but I have coded plenty of WinForms apps and I feel like it's taken me approx. 3 times longer to build this MVC app. The initial investment is a bear, but regular maintenance and improvements seem to come WAY faster, especially as the app has grown... Since you seem to have a team of programmers, it may come faster for you guys as you can probably split up the learning/workload.

  4. Again, no prior experience with WebForms, but what I can tell you is that as I was learning ASP.NET MVC, there were times when I was struggling to understand what was going on because I had no prior ASP.NET background. (Example: Membership and Role Providers -- I had to code my own recently. Boy was that fun...) On the plus side, I didn't have any "old ways of doing things" (aka. WebForms) to unlearn either. If you have a team of folks enamored with PostBack / CodeBehind, you can bet that MVC is gonna seem awfully strange at first. But hopefully your team will see the advantages that MVC brings and embraces it fully.

Oh, and it should be noted that you can blend MVC and WebForms. It's not an all-or-nothing proposition. Although, if I were in your shoes, I'd try to embrace MVC as much as possible and only use WebForms where it clearly makes more sense.

Ok, I hope this helps... :-)

一紙繁鸢 2024-07-24 20:08:43

我可以回答你一半的问题。 我刚刚从 WebForms 背景开始涉足 MVC。 (显然)有一个学习曲线,但实际上并不是很陡峭。 我毫不费力就完成了转变,我发现整个事情就像呼吸新鲜空气一样。

不过,我对前端技术(HTML 和 Javascript)很有能力,而且我不喜欢 WebForms 和 Microsoft ajax 框架生成的 HTML。 如果您和/或您的团队是这样的,您一定会喜欢它。 但是,如果您对自己对事件层次结构的深入了解感到自豪,或者如果您喜欢 UpdatePanel 的简单性,那么您可能会拒绝这些更改。

无论如何,文档还可以,足以让我们愉快地进行下去。 这里有一些视频可以吊起你的胃口:
http://videos.visitmix.com/MIX09/T49F
http://videos.visitmix.com/MIX09/T50F
http://videos.visitmix.com/MIX09/T44F

这是您的文档主页:
http://www.asp.net/mvc/

有关更多信息,请参阅第一章《asp.net mvc 1.0》一书已上线,可以免费下载。 请参阅 ScottGu 的博客:
http:// weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx

而且,本章的完整代码可以在这里找到:
http://www.codeplex.com/nerddinner

最后,就开发时间而言,我认为使用 MVC 开发应用程序可能需要更长的时间(尽管我没有证据表明这一点),但我认为支持、维护、错误修复和增强将花费更少的时间。 因此,只要进行少量的前期投资,我认为您将获得更多的回报。

不管怎样,就像我说的,这些是我的初步发现。 我还没有遇到一个真正棘手的问题。

I can answer half of your question. I've just dove into MVC from a WebForms background. There is (obviously) a learning curve, but it's really not very steep. I've been able to make the transition with little effort, and I find the whole thing to be a breath of fresh air.

However, I am quite capable with front-end technologies (HTML & Javascript), and I don't like the HTML the WebForms and Microsoft ajax framework generates. If you and/or your team are like this, you will love it. However, if you are proud of the in-depth knowledge you have of the event hierarchy, or if you love the simplicity of UpdatePanels, then you'll probably bridle against the changes.

The documentation is OK, enough to get going happily, anyway. Here's a few videos to whet your appetite:
http://videos.visitmix.com/MIX09/T49F
http://videos.visitmix.com/MIX09/T50F
http://videos.visitmix.com/MIX09/T44F

Here's your documentation home:
http://www.asp.net/mvc/

For a bit more info, the first chapter of the asp.net mvc 1.0 book is online and can be downloaded for free. See ScottGu's blog here:
http://weblogs.asp.net/scottgu/archive/2009/03/10/free-asp-net-mvc-ebook-tutorial.aspx

And, the full code for the chapter can be found here:
http://www.codeplex.com/nerddinner

Finally, in terms of development time, I think it might take a bit longer to develop apps using MVC (although I have no evidence of this), but I think supporting, maintaining, bugfixing and enhancing will take a lot less time. So, with a small up-front investment, I think you'll more than recoup that effort.

Anyway, like I said, these are my preliminary findings. I still have yet to hit a really hairy problem.

一笔一画续写前缘 2024-07-24 20:08:43

如您所知,一切都是以人为本,技术其次。 您可以简单地为公司应用程序构建一个新功能,因为它们可以共存,然后您可以自己回答所有这些问题。
这是新东西,所以它当然会比你习惯的花费更多的时间,但它很有趣,所以直接跳进去,开始为你自己的人和应用程序回答这些问题。

As you know its all about the people first, technology 2nd. You can simply build out a new functionality of your company app because they can co-exist, then you can answer all those questions yourself.
It's new stuff so it will of course take more time than what you're used to but heck its all fun so jump right in and start answering these questions for your own people and app.

荆棘i 2024-07-24 20:08:43

有趣的是,您的问题全部集中在您的担忧上,而不是任何好处。 你问过自己“为什么”的问题吗? 如果您认为使用 WebForms 可以取得成功,为什么要改用 MVC? MVC 中的哪些内容可以证明这些风险是合理的? 如果你为这个项目付费,你会做什么?

我并不是以任何方式推销 WebForms 而不是 MVC,但作为一名架构师,您需要能够非常强烈地回答为什么您决定从一个非常知名的数量转向一个相对较新的数量的问题。 我认为这样做有很多充分的理由,但这与我的工作无关。 :)

Interesting that your question focused all on your concerns and not on any benefits. Have you asked yourself the "why" question? If you feel you can be successful with WebForms, why change to MVC? What is there in MVC that justifies the risks? If you were paying for the project, what would you do?

I'm not pitching WebForms over MVC by any means, but as an architect, you need to be able to come back very strong to the question of why you decided to go away from a very well-known quantity to a relatively new one. I think that there are many good reasons to do so, but it not my job on the line. :)

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文