Both ASP.NET MVC and WebForms are web application frameworks, with MVC gaining popularity for its code cleanliness, separation of concerns, and flexibility.

Key Differences

1. Request Handling

• WebForms: Uses a page controller model where a single page (web form) handles all tasks like request processing, UI rendering and event handling.
• MVC: Adopts the Front Controller pattern where the Controller is the entry point, directing requests to specific actions. Each action maps to a view, offering finer control.

2. Routing

• WebForms: Rely on URL mappings established in the <system.web> section of web.config.
• MVC: Employs a powerful attribute-based routing mechanism. Entities can be assigned their unique URLs based on URL templates.

3. State Management

• WebForms: Abstracts the HTTP stateless nature through mechanisms like ViewState, Session, and Control State.
• MVC: Uses a stateless approach, offering more transparency and control. Stateful actions are supported via Context objects or custom implementations.

4. HTML Generation

• WebForms: Features server controls that render HTML based on the server-side logic written in ASP.NET.
• MVC: Offers highly-lauded Razor syntax for a more structured generation of dynamic web content.

5. Testability

• WebForms: Is less testable due to event-driven architecture.
• MVC: Separation of concerns makes components easier to test in isolation, facilitating unit and integration testing.

MVC, an architectural pattern first introduced by Smalltalk-80, is now widely adopted across various platforms like ASP.NET MVC and others.

Key Components

• Model: Represents the application’s logic, data, and rules. It is independent of the UI and directly interacts with the database, API, or any data source.
• View: The visual representation or user interface presented to users. Views render the data provided by the model in a format that is suitable for user interaction.
• Controller: Acts as an intermediate link between Model and View. It handles user input, processes them, and updates the Model and/or View as necessary.

Architecture Flow

1. Client Request

• A user initiates an action, like submitting a form or clicking a link.
• The Controller is responsible for capturing and managing such user actions.

2. Controller Action

• The Controller liaises with the model to retrieve the requested data or to store user input.
• It chooses the appropriate View to display based on the requested action.

3. Model Interaction

• The Model, following the instructions from the Controller, processes or retrieves the necessary data.

4. View Rendering

• The View presents the processed data from the Model in a user-friendly format.
• The rendered View is then returned as a response to the client.

Loose Coupling and Separation of Concerns

In the MVC architecture:

• Loose Coupling ensures components can function independently. For instance, a different View can be associated with a Controller without changing the original setup.
• Separation of Concerns keeps distinct roles of components. A well-constructed MVC project limits cross-component dependencies, making maintenance and scalability easier.

Code Example: ASP.NET MVC Controller Related Code

Here is the C# code:

public class BookController : Controller
{
    private BookRepository _bookRepository; // Access to the Model

    public BookController()
    {
        _bookRepository = new BookRepository();
    }

    // GET: /Book/
    public ActionResult Index()
    {
        // Retrieves a list of books from the Model
        var books = _bookRepository.GetAll();
        return View(books);  // Returns the data to a View for rendering
    }

    // GET: /Book/Details/5
    public ActionResult Details(int id)
    {
        var book = _bookRepository.GetByID(id);
        return View(book);
    }

    // GET: /Book/Create
    public ActionResult Create()
    {
        return View();
    }

    // POST: /Book/Create
    [HttpPost]
    public ActionResult Create(Book book)
    {
        if (ModelState.IsValid)
        {
            _bookRepository.Add(book); // Updates the Model
            return RedirectToAction("Index");
        }
        return View(book);
    }

    // Other action methods for Edit, Delete, etc.
}

In this example:

• The Controller (BookController) mediates user interaction for operations related to books.
• The Model (BookRepository) encapsulates the data fetching, updating, and storage logic. It is accessed by the Controller through a private field.
• The View is the user interface for different actions, for example, rendering a list of books in the Index action.

ASP.NET MVC is a web application framework that separates the application into three main components: Model, View, and Controller.

Model

The Model is responsible for managing the data, business rules, logic, and objects of the application. It retrieves this data from the database and stores it there as well, functioning as the data management layer.

Core Characteristics

• Data Retrieval: The model retrieves data from the database or any other data source.
• Business Logic: It contains the application’s business logic responsible for processing data before passing it to the View or Controller.
• State Management: The Model represents the application’s data state, and any change in the Model automatically updates the associated Views.
• Data Validation: The Model validates the data before passing it to the database.

Additional Notes

• The model in MVC is often represented as either a single object or a collection of objects.
• It can also encapsulate the logic required to update the database.

View

The View is the component that is responsible for displaying or presenting the user interface. It is a User Interface layer.

Key Functions

• Data Presentation: The View presents data to the user in a human-readable format.
• Data Output: It outputs the data to be viewed by the end-users.

Characteristics

• Passive Role: There’s minimal or no processing done within the View.
• Data Presentation Only: It doesn’t contain any application logic.

Note

• Views in ASP.NET MVC are not just limited to HTML views. They can be any form of a user interface, such as XML files, plain text, or even JavaScript-based interfaces.

• A significant and distinct concept in Views is the use of display and editor templates. These are small, reusable templates specifically designed to render properties of models consistently.

Controller

The Controller acts as an intermediary between the View and the Model. It processes incoming requests, manipulates data using the Model, and selects the View to generate the response.

Key Functions

• Request Handling: It handles HTTP requests from the users or clients.
• Business Logic Coordination: The Controller coordinates the application’s business logic.
• View Selection: After processing the request, the Controller selects the appropriate View for sending the response to the user.

Key Characteristics

• No Direct Data Management: The Controller doesn’t directly handle data management.
• State Management: It maintains the application’s state during requests and keeps track of various components involved in a user’s interaction.

Triggering Workflow

1. Request: The client sends an HTTP request.
2. Routing: The routing engine maps the URL to the corresponding Controller action.
3. Controller: The appropriate action method of the Controller is invoked.
4. Model: If required, the Model is updated based on the request data.
5. View Rendering: The action method selects an appropriate View, and the Controller sends the resultant data and the View to the client for rendering.

Code Example: A Simple Controller

Here is the C# code:

public class HomeController : Controller
{
    private readonly IEmployeeRepository _employeeRepository;

    public HomeController(IEmployeeRepository employeeRepository)
    {
        _employeeRepository = employeeRepository;
    }

    public IActionResult Index()
    {
        var employees = _employeeRepository.GetAll();
        return View(employees);
    }

    // Other action methods for Create, Edit, and Delete
}

In ASP.NET MVC, routing enables the mapping of URLs to Controller Actions, functioning as the starting point for request handling. ​ The application begins by extracting route data from the incoming URL and matching it to defined route templates.

Key Concepts

• Route Collection: A set of defined URL patterns converted into Route objects, typically found in the RouteCollection of RouteConfig.

• RouteConfig: The specialized class where route registration is centralized.

Route Constraints and Defaults

Constraints validate the URL fields specified in the route and impose restrictions, while defaults are used when a route value is absent, supplying a predetermined value.

Route Engine Functions

The route engine employs the following to find the best route match:

• URL Matching: By scanning the route collection to identify the most compatible route.

• Route Template Parsing: Extracting route data from the URL itself.

Order of Operations and Best Practices

It’s best to establish a profound understanding of the route-handling mechanism and adhere to best practices, like listing routes in descending order of specificity, to optimize URL mapping.

The Controller in the Model-View-Controller architecture handles user requests and updates the model. ASP.NET MVC keeps controllers distinct, offering clear separation for data and UI components.

Basic Responsibilities of a Controller

1. Serving Requests: Interacts as a focal point between the user and the system, dealing with web requests such as form submissions or URL routing.
2. Data Transformation: Transforms user inputs into actions that the model and view can interpret, such as processing data from a form submission.
3. Routing URL: Matches incoming URL requests to defined action methods.
4. Handling Results: Orchestrates the flow of both user inputs and system outputs, directing the final result to the appropriate view.

Controller vs. Model/View

• Controller vs. Model: The Controller oversees input data management, evaluates that data, and sends instructions to the model. In contrast, the model, accommodating these instructions, manipulates data.
• Controller vs. View: The Controller, after analyzing input data, selects the appropriate view for the result. It then populates this view with model data.

MVC Request Lifecycle

1. Routing: Requests are initially directed based on URL patterns.
2. Controller Selection: The selected controller is prepared to handle the incoming request.
3. Action Execution: Controllers initiate relevant action methods based on the request.
4. Result Generation: Results from action methods are directed to the appropriate view.

The ASP.NET MVC request lifecycle is a sequence of events that starts when a user requests a web page and ends when the page is rendered and sent back to the browser.

Key Phases of the ASP.NET MVC Request Lifecycle

1. Routing: The URL is parsed to determine the controller, action, and parameters.
2. Controller Initialization: The corresponding controller is instantiated.
3. Action Method Selection: The desired action method is located based on the incoming request.
4. Action Method Execution: The selected action method is executed.
5. Result Execution: The action method result is executed and rendered.

Code Example: Controller and Action Method

Here is the C# code:

using System.Web.Mvc;

public class HomeController : Controller
{
    public ActionResult Index()
    {
        return View();
    }
}

Detailed Request Lifecycle Steps

1. Routing: This phase is responsible for analyzing the incoming URL and determining the corresponding controller and action. This is accomplished using a router, and default routing is provided for convenience.

2. Controller Initialization: After the controller and action are determined, the appropriate controller is instantiated using a controller factory. This enables you to customize the process of controller creation if needed.

3. Action Method Selection: The system locates the action method within the instantiated controller corresponding to the user’s request, typically through reflection. Variants like public methods matching the HTTP method or decorated with specific attributes can be selected.

4. Action Method Execution: Selected action methods are invoked, during which they can perform necessary tasks, such as data retrieval, manipulation, or interaction with other components.

5. Result Execution: The ActionResult produced by the action method is executed, which could involve rendering a view, returning a HTTP response, or performing custom behavior.

In the context of ASP.NET MVC, an action represents a unit of work that a controller performs, handling requests from users and preparing responses. Each action method uses attributes to specify the HTTP methods it responds to.

Here are the fundamental components of an action method:

Action Method Elements

1. ControllerActions methods of controllers that handle incoming HTTP requests.
2. Attributes such as [HttpGet] and [HttpPost] define which HTTP methods the action responds to.
3. Return Type dictates the type of content the action method returns, such as a JsonResult, PartialViewResult, or ViewResult.
4. Parameters of the action method can be delivered using route data, query string, request body, or form data.

Code Example: Action Methods

Here is the C# code:

// Controller: Product
public class ProductController : Controller
{
    [HttpGet] // Responds to HTTP GET requests
    public IActionResult Index()
    {
        // Retrieve and return a list of products
        return View("Index", productList);
    }

    [HttpPost] // Responds to HTTP POST requests
    public IActionResult AddProduct(Product newProduct)
    {
        // Add product to the data store
        return RedirectToAction("Index");
    }

    // Custom route definition
    [HttpGet("products/{id}")] // Responds to /products/{id} using a custom route
    public IActionResult ProductDetail(int id)
    {
        // Retrieve product by id and return it
        return View("ProductDetail", product);
    }
}

HTTP Methods and Actions

In many interactive web applications, HTTP requests necessitate different responses based on the HTTP method used. Each method corresponds to specific user actions, enabling the server to react appropriately.

• GET: Requests data from the server (e.g., displaying a product catalog or obtaining user profile data).
• POST: Sends data to the server for a new operation (e.g., adding a product to a shopping cart or submitting a form for user input).
• PUT: Updates data on the server (e.g., modifying user profile information).
• DELETE: Removes data from the server (e.g., removing an item from a shopping cart).

ASP.NET MVC simplifies the process of handling these different request types through the use of attributes.

Benefits of Using Action Attributes

Attributes streamline the process of guiding HTTP requests to the correct action methods.

• Explicitness: Attributes offers visually explicit instructions about a method’s behavior related to HTTP methods and routing.
• Simplicity: The inclusion of attributes in close proximity to the method declaration enhances the method’s clarity and purpose.
• Consistency: Using attributes ensures uniformity in how methods respond to HTTP requests within the entire application.

Security Considerations

Bound methods have associated HTTP methods and are accessed directly from external client requests. Always exercise caution and implement appropriate security measures, such as input validation, to fortify your application against potential vulnerabilities, like Cross-Site Request Forgery (CSRF).

Backup Plan for Missing Actions

Should a bound method be unavailable, ASP.NET MVC will generate an HTTP 404 (Not Found) response. This safety mechanism prevents unintended access to resources that you might choose not to make public.

Razor is a view engine used in ASP.NET MVC and ASP.NET Web Pages, designed for generating web pages optimally with minimal syntax.

Key Features

• Data Binding: Razor uses C# code blocks (@{ ... }) for dynamic data integration.
• Clean Syntax: Its clean and minimal syntax, envisioned for HTML templates, simplifies template design.
• IntelliSense Integration: Razor offers improved IntelliSense support over older engines like ASPX.
• Reusability: It promotes code reusability via partial views and layout pages.

Razor Syntax Overview

• **@**: Allows infix incorporation of C# code in your HTML markup.
• HTML Helpers: Furnish a more expressive way to render HTML controls using C# methods.
• Partials and Layouts: Razor encourages a modular approach via @Html.Partial and @RenderSection for composing layouts.

Code Example: Razor Template

@model Namespace.To.Your.ViewModel

@{
    ViewData["Title"] = "Home";
    Layout = "~/Views/Shared/_Layout.cshtml";
}

<h2>Welcome to our application, @Model.UserFullName!</h2>

@Html.Partial("_RecentPosts", Model.RecentPosts)

<footer>@DateTime.Now.Year</footer>

Controllers serve as intermediaries between Models and Views in the MVC (Model-View-Controller) architecture. They prepare and transfer data to the Views for presentation. Two primary methods for passing data are:

ViewData

• Controller: Set ViewData as a key-value pair.
• View: Retrieve data using ViewData["key"].

// Controller
public ActionResult Index()
{
    ViewData["Message"] = "Welcome to the Index page!";
    return View();
}

// View
<h2>@ViewData["Message"]<h2>

ViewBag

• Controller: Use ViewBag similarly to ViewData.
• View: Access data using dynamic properties.

// Controller
public ActionResult Index()
{
    ViewBag.Message = "Welcome to the Index page!";
    return View();
}

// View
<h2>@ViewBag.Message</h2>

In ASP.NET MVC, sessions provide a way to persist data across multiple requests for a user’s browsing session. The state is stored on the server, while the client gets a unique identifier, usually in the form of a cookie, to manage the session.

Session Providers

ASP.NET MVC allows for different session management strategies, each suited to particular use-cases.

InProc

• Description: Session data is stored in the web server’s memory, making this method the quickest. This is the default mode.
• Best Fit For: Small applications which require a simple and fast session management mechanism.
• Limitations:
  • Not suitable for web farms or server clusters.
  • All session data is lost if the server restarts, doesn’t handle sudden spikes in traffic well, and can lead to a session-waiting request deadlock.

State Servers

• Description: The session state is stored separately in a separate process called the ASP.NET State Server.
• Best Fit For: Websites deployed in a server farm or web garden environment.
• Limitations:
  • Since session data is stored outside the web application, it must be serializable.
  • Data resides only in the memory of the ASP.NET state server, meaning the server can’t restart without losing all session data.
  • Adds some latency to your application.

SQL Server

• Description: The session state is stored in a SQL Server database.
• Best Fit For: Scalable, fault-tolerant web applications.
• Limitations:
  • Requires additional infrastructure (a database server).
  • Slower than the default ‘InProc’ mode due to the database transactions.
  • Session data must be serializable to be stored in SQL Server.
  • It’s essential to tune the database properly to ensure efficient performance.

Redis

• Description: Uses a Redis cache as a backend store for session state.
• Best Fit For: Scalable and high-performance web applications.
• Limitations:
  • Requires a running Redis server. Extra overhead in managing and maintaining the Redis server.
  • Slightly slower than InProc mode due to the network round trip to the Redis server.

Custom

• Description: Developers can build their session state modules.
• Best Fit For: Extremely specific requirements not covered by the options provided out of the box.
• Limitations:
  • Requires additional coding and thorough testing.

Configuration in Web.config

You can specify the session state mode in your Web.config file using the sessionState section. For instance, to specify SQL Server as the session mode, you would use:

<configuration>
  <system.web>
    <sessionState mode="SQLServer"
      sqlConnectionString="Data Source=myServerAddress;Initial Catalog=myDataBase;Integrated Security=True"
      cookieless="false"
      timeout="20" />
  </system.web>
</configuration>

ASP.NET MVC provides different mechanisms to pass data from the controller to the view at various stages of a user’s request. These mechanisms include ViewData, ViewBag, and TempData.

Types of Data in ASP.NET MVC

• ViewData: A container for passing small amounts of data from controller to the related view. This is useful when submitting form data to be displayed back in the case of errors.

• ViewBag: A dynamic wrapper around ViewData which acts as a quick-and-easy way to shuttle data between Controllers and Views.

• TempData: A session-backed mechanism meant to survive only until its value is read. This is useful for passing data which needs to persist between requests, such as messages for redirection after an action or one-time confirmation messages.

Code Example: Using TempData

Here is the C# code:

Controller Action to Set TempData

public ActionResult Index()
{
    TempData["FeedbackMessage"] = "Saved successfully!";
    return RedirectToAction("Details");
}

Controller Action to Read TempData

public ActionResult Details()
{
    ViewBag.Message = TempData["FeedbackMessage"];
    return View();
}

View to Display Message

@if (ViewBag.Message != null)
{
    <div class="alert alert-success">
        <strong>Success!</strong> @ViewBag.Message
    </div>
}

In the View, such as Details.cshtml, the ViewBag.Message will display the message set in the Index action.

Potential Pitfalls

• Data Loss: For all these mechanisms, if data set in the controller doesn’t get displayed, it can be lost.

• Cleanliness: Keeping the Views clean from clutter by avoiding using them as data transmission mechanisms. Instead, use more structured forms or models for data input and display.

• Reusability: Ensuring that data passed from the controller doesn’t become tied to a specific display context, it won’t make the View to be reusable.

HTML Helpers in ASP.NET MVC are methods that simplify the task of generating HTML markup. They offer a consistent way to produce UI elements and can be bound either manually or automatically.

Comprehensive support is provided for these QR codes:

• Authentication: QR codes may be used for two-factor authentication. For example, Google Authenticator generates QR codes to synchronize with your accounts.
• Payments: Some mobile banking apps use QR codes for quick peer-to-peer payments.

Benefits of Using HTML Helpers

• Code Reusability: You don’t have to write the same HTML repeatedly. Abstraction allows you to reuse code segments as needed.

• Type Safety: Using HTML Helpers guarantees that you’re providing the appropriate data types, such as a string or numeric value.

• Intellisense Support: Developers are aided with prompts and suggestions during code development.

Categories of HTML Helpers

1. Standard HTML Helpers: Common UI components such as text boxes, labels, and dropdowns fall under this category.

2. Strongly Typed HTML Helpers: These are associated with model classes and are handy for functions like form submissions and control display.

3. Templated HTML Helpers: They are used for creating custom view templates, which makes modifications to the default rendering for various data types.

4. Extension Methods: These helpers are integrated directly into the HtmlHelper class, permitting your own extensions.

Advantages of HTML Helpers Over Inline HTML

• Unit test-ability: HTML Helpers can be tested using unit test frameworks, ensuring that the generated HTML is correct.

• Extensibility: You may create custom HTML Helpers to cater to specialized UI requirements.

• Code Readability: By encapsulating complex rendering logic, your view files remain concise and easy to understand.

When to Use HTML Helpers versus Inline HTML

• HTML Helpers are beneficial when developing larger applications with larger teams. They offer a structured approach to generate HTML.

• Inline HTML is fine for smaller projects. However, using it in large applications can lead to inconsistencies and maintenance difficulties.

Code Example: HTML Helper for Text Input

Here is the C# code:

@Html.TextBoxFor(model => model.Age, new { @class = "form-control", placeholder = "Enter your age" })

Code Example: Inline HTML

Here is the HTML code:

<input type="text" id="age" name="Age" class="form-control" placeholder="Enter your age">

Visual Studio Extensions for HTML Helpers

• Razor Toolbox: Provides a dedicated toolbox for Razor HTML Helpers.

• MVC Controls Toolkit: Offers various rich, responsive controls optimized for ASP.NET MVC.

Model Binding automates the transfer of data between HTTP requests, web forms, and business objects. In ASP.NET MVC, this process involves matching form data or query-string parameters to object properties using customizable conventions.

Key Concepts

• Model: Represents a business object being constructed or modified. It commonly aligns with a view-specific ViewModel or action method parameter.

• Value Providers: Extract data from HTTP requests, such as query strings or form data. Each method in ValueProvider retrieves data from one specific data source like QueryStringValueProvider or FormCollectionProvider.

Model Binding Pipeline

The platform uses a step-by-step mechanism to piece together and validate a model from incoming data.

1. Value Provider Composition: ASP.NET MVC assembles several ValueProviders that source data from candidate locations like the route data, request query string, or browser cookies.

2. Data Extraction and Prefix Handling: Data pertinent to a specific model is discerned based on prefixes. This step also ensures that any findings are filtered by the model’s specific prefix, which avoids conflicts or data leakages from other models.

3. Data Conversion: The extracted strings are transformed into the target property types using formatter classes such as ModelBinder.

4. Validation: The validated model state, if necessary, undergoes further model-level validation. Respectively, the platform can tab into IValidatableObject.

5. Model Population: Conclusively, the model is populated with the validated and transformed data that satisfies the earlier steps. This populated model is then handed off to the controller action as a formal parameter.

Code Example: Model Binding

Here is the C# code:

public class MyController : Controller
{
    [HttpPost]
    public ActionResult SaveGame(GameViewModel model)
    {
        if (ModelState.IsValid)
        {
            // Process the model
            return RedirectToAction("Success");
        }

        // Model is not valid - render back the form with errors
        return View(model);
    }
}

In this example, GameViewModel is the binding model, and SaveGame is an action method that will be invoked when the form is submitted. The model parameter represents the data that has been bound from the request body, and internal validation is then checked using ModelState.IsValid. If validation fails, the view is rendered back with errors.

The ViewStart file in ASP.NET MVC allows you to define common settings, such as the Master Layout and other Razor directives that are applied to all views within a specific directory or the project.

Key Functions

1. Globalized Settings: Instead of specifying a Layout in each View file individually, you can set it once in the ViewStart file. This is useful for consistency across the application.

2. Default Settings: The ViewStart defines default settings to reduce redundancy and improve code maintainability.

3. Multi-level Cascading: The ViewStart’s settings can trickle down into subdirectories, streamlining global and localized settings.

Code Example: ViewStart.cshtml

Here is the content of ViewStart.cshtml:

@{
    Layout = "~/Views/Shared/_MasterLayout.cshtml";
    ViewData["GlobalHeader"] = "Welcome to My Site";
}

In ASP.NET MVC, Partial Views and View Components serve similar purposes by letting you split complex UI logic into more manageable chunks. However, each has its unique role and characteristics.

Core Differences

• Lifecycle: Partial Views are rendered as part of a parent view. Once the parent view is complete, partial views also render. In contrast, View Components are independent units and can be rendered from inside a view or a controller.

• Strongly Typed Model: Partial Views can share the same model as the parent view. Therefore, any model needed in a child view needs to be passed from the parent. View Components, on the other hand, define their individual model, making them more consistent and self-contained.

• Razor Syntax: Partial Views utilize Razor syntax, which allows for inline C# code with @ directives. View Components, operating as standalone units, are coded inside a class and leverage @functions for code.

• Render Mechanism: You render a Partial View by calling the Html.Partial or Html.RenderPartial method. A View Component, in contrast, is invoked using a tag helper or ViewComponent() method.

• Caching: View Components are more powerful in scenarios where caching is required. They support both client and server-side caching out-of-the-box, providing more fine-grained control over cache durations and invalidation.

• Complexity: Partial Views are a simpler, longstanding feature of MVC, often handling basic UI elements like headers or footers. View Components are more recent additions, intended to handle complex view logic in a modular, reusable manner.

When to Use Which

• Complex UI Logic: When you need to encapsulate complex UI logic that requires its own controller-like structure, View Components are the way to go.

• Reusability: View Components offer better encapsulation and reusability, making them a preferred choice for components such as navigation menus or shopping carts that are used across many views.

• Performance and Caching: If caching or better performance are priorities, View Components are the recommended choice due to their built-in support for caching mechanisms.

• Simplicity and Quick Wins: For simpler UI elements, or when the intention is to rapidly build a view without worrying about a separate controller or caching, Partial Views are an efficient choice.

• Model Consistency: If you desire a view component to have a consistent, predefined model, View Components with their explicit model declaration are the better fit. If reusability across different parent view models is necessary, a Partial View is more suitable, provided the parent is responsible for passing necessary models.

• Debugging and Maintenance: Partial Views are easier to manage within the context of their parent views, making them faster to debug. But if a component requires its debugging context or has significant individual logic, a View Component might be more efficient in the long run.