ASP.NET Core 2中View与Page的区别及相关技术疑问

Hey there! Let's break down all your questions about ASP.NET Core 2's Razor Pages vs. traditional MVC Views—this is such a common point of confusion when starting out, so I’m glad you asked.

First, let’s get clear on how these two differ:

• Structure & Routing: Razor Pages uses a file-based routing system—the path to your .cshtml file directly maps to the URL (e.g., Pages/About.cshtml becomes yourdomain.com/About). Views rely on MVC controllers and configured route templates, so you need a controller action to return a view.
• Code Organization: With Pages, your page logic lives in a paired .cshtml.cs code-behind file right next to the view, keeping everything related to that page in one place. For Views, logic is separated into controller classes, with views in the Views folder tied to controller actions.
• Model Binding & Logic: Razor Pages have a PageModel class that handles model binding, validation, and page-specific logic directly. In MVC, this logic is spread across controllers and view models, which can add extra layers for simple pages.

Razor Pages were added specifically to simplify page-driven development, and they shine in a few key areas:

• Less Boilerplate: No need to create empty controller classes just to serve a page—you can jump straight to writing page-specific logic.
• Clearer Separation of Concerns: Each page owns its own logic, so it’s easier to track down where code lives compared to sprawling MVC controllers that handle multiple actions.
• Intuitive Routing: File-based routing means you don’t have to mess with route templates for basic pages—just create a file, and it’s accessible via the corresponding URL.
• Smoother Transition for Web Forms Devs: If you’re coming from ASP.NET Web Forms, the code-behind model of Razor Pages feels much more familiar than MVC’s controller-view separation.

Opt for Razor Pages if: #

• You’re building a small to medium-sized, page-focused app (like an internal tool, blog, or simple e-commerce site).
• You want to prototype quickly without getting bogged down in MVC’s controller structure.
• Your pages have self-contained logic that doesn’t need to be shared across multiple views.

Stick with MVC Views if: #

• You’re working on a large, complex application that requires a robust separation between business logic and presentation (like a full-scale SaaS platform).
• You need to build RESTful APIs alongside your web interface (MVC controllers are still the go-to for API endpoints).
• Your project already uses an MVC architecture, and you don’t want to mix patterns unnecessarily.

Absolutely! ASP.NET Core fully supports mixing Razor Pages and MVC in the same project. Here’s how it works:

• In your Startup.cs (or Program.cs for newer versions), just make sure you register both services: services.AddMvc().AddRazorPages();
• The routing system will automatically handle both: Razor Pages use their file-based routes, while MVC routes are handled by controller actions.
• For example, you could have an MVC HomeController with an Index action that returns a view, and a Razor Page at Pages/Contact.cshtml that’s accessible at yourdomain.com/Contact—both will work side-by-side without conflicts.

Hope that clears up all your questions! If you’re just starting out, I’d recommend tinkering with Razor Pages for a small test project first—it’s a great way to get comfortable with ASP.NET Core without the overhead of MVC.

内容的提问来源于stack exchange，提问作者topcool