ASP.NET Core Razor Pages vs MVC: Key Concepts Quiz Quiz

Explore the core differences, workflows, and advantages of ASP.NET Core Razor Pages and MVC architectures with this quiz, designed to help learners grasp routing, page models, and development patterns used in each approach. Strengthen your understanding of how each model impacts web application structure and development strategies.

  1. Routing in Razor Pages vs MVC

    Which statement correctly describes the routing mechanism in Razor Pages compared to MVC?

    1. Razor Pages and MVC both require manual registration of every endpoint in a custom route table.
    2. Both use only attribute routing with no folder structure involved.
    3. MVC relies entirely on folder/file names for routing, while Razor Pages needs separate route configuration for each page.
    4. Razor Pages rely on folder and file paths for routing, whereas MVC uses controller/action routing conventions.

    Explanation: Razor Pages use the organization of folders and files to automatically determine their route, while MVC uses controller and action naming conventions to define URL routes. The second option is incorrect because MVC's default routing is convention-based, not solely attribute-based. The third and fourth options misrepresent the way routing works in MVC and Razor Pages; neither requires manual registration of every route.

  2. Location of Page Logic

    In Razor Pages, where is the page-specific logic such as handling form submissions typically placed?

    1. In the main Startup logic
    2. In a code-behind PageModel class associated with each Razor Page file
    3. Within a global AppLogic class
    4. Directly in the view's HTML only

    Explanation: Razor Pages separates page logic into a PageModel class that acts as the code-behind for the corresponding page file, making it easy to keep logic organized and close to the view. Placing logic in Startup is for configuration, not page processing. Pages do not handle logic directly in HTML. The AppLogic class is not a standard pattern for page-specific concerns.

  3. MVC Design Pattern Core

    Which architectural pattern is central to MVC web applications?

    1. Page-Handler-Model
    2. Model-View-Controller
    3. Model-Page-View
    4. Page-Model-View

    Explanation: MVC stands for Model-View-Controller, which clearly structures app logic, presentation, and data. 'Page-Model-View' and 'Model-Page-View' are not standard patterns. 'Page-Handler-Model' describes the Razor Pages approach more closely, but is not the official design pattern for MVC.

  4. File Structure Differences

    How do Razor Pages and MVC generally differ in terms of project file organization?

    1. Razor Pages organizes files alphabetically only.
    2. Razor Pages organizes files by features/functions, whereas MVC typically structures files by type such as controllers and views.
    3. MVC requires all files to be placed in a single folder.
    4. Both strictly organize files by year of creation.

    Explanation: Razor Pages encourages grouping files related to a specific feature together, making feature organization natural. MVC uses separate folders: for example, controllers in one, views in another. Organizing by year or requiring all files in one folder is incorrect and impractical for real projects.

  5. URL Example for Each Pattern

    Given a 'Products' page, what is a likely URL for that page in a default Razor Pages and MVC application?

    1. /Products/Index for Razor Pages and /Products for MVC
    2. /Home/Products for Razor Pages and /Products/Index for MVC
    3. /Index/Products for both
    4. /Products for Razor Pages and /Products/Index for MVC

    Explanation: In Razor Pages, the folder and file determine the URL, often resulting in clean URLs like '/Products'. MVC uses '/Products/Index' by default, reflecting the controller and action. The other answer choices mix up conventions or suggest URLs not typical to either pattern.

  6. Handling HTTP Verbs

    In Razor Pages, how do you typically handle GET and POST requests for a page?

    1. By creating OnGet and OnPost handler methods in the PageModel
    2. By writing handlers in the _Layout file
    3. By using only one method for both verbs
    4. By defining separate controllers for each verb

    Explanation: Razor Pages uses distinct OnGet and OnPost handler methods inside the PageModel to process GET and POST requests. MVC uses controllers, not Razor Pages. Using a single method for both HTTP verbs is not recommended. The layout file is for shared HTML and does not process requests.

  7. Use Case Fit

    Which scenario is most suitable for using Razor Pages over MVC?

    1. When separating business and presentation logic is unimportant
    2. When building simple or form-based pages with minimal logic
    3. When constructing a large-scale RESTful API with many endpoints
    4. When developing applications that require heavy use of multiple controllers

    Explanation: Razor Pages simplify scenarios with limited logic and a clear focus on page-centric workflows, such as forms or simple pages. While RESTful APIs and complex controller logic fit the MVC pattern better, disregarding business and presentation logic separation is not a valid approach for either paradigm.

  8. Data Binding Approach

    How is data typically bound to the view in Razor Pages compared to MVC?

    1. Data binding is done exclusively via session storage in both paradigms.
    2. Razor Pages use public properties in the PageModel, while MVC uses ViewData, ViewBag, or Model objects passed from controllers.
    3. MVC injects data directly through HTML, while Razor Pages do not support data passing.
    4. Both use only ViewBag for data binding.

    Explanation: Razor Pages utilize properties in the PageModel for exposing data, whereas MVC commonly uses ViewData, ViewBag, or sets the Model for views. ViewBag alone is not the sole technique, and both frameworks allow more structured data passing. Session storage is not the primary mechanism for data binding in either approach.

  9. Partial Views and Reusability

    Which option best describes the use of partial views in Razor Pages and MVC?

    1. Partial views are used only for routing between pages in Razor Pages.
    2. Partial views must always be placed in the root directory in both architectures.
    3. Only MVC supports partial views; Razor Pages does not.
    4. Both Razor Pages and MVC support the use of partial views for reusing markup components.

    Explanation: Marking up reusable pieces with partial views is supported by both architectures, enhancing maintainability and DRY principles. The claim that only MVC supports partial views or that partials must be in the root directory is incorrect. Partial views are not a mechanism for routing.

  10. Separation of Concerns

    How do Razor Pages and MVC both help achieve separation of concerns in web applications?

    1. By only focusing on separating HTML and CSS
    2. By storing all code and markup in a single file per page
    3. By keeping data access logic, view markup, and request handling in separate places within the app structure
    4. By requiring no logical separation at all

    Explanation: Both architectures promote keeping functionalities like data access, presentation, and request-handling separated—in MVC via controllers and models, and in Razor Pages via PageModels and page files. Consolidating all code in one file or focusing merely on HTML and CSS does not address full separation of concerns.