I have a New and Edit view that basically contain duplicate cshtml. What's the most efficient way to refactor so I can stay DRY?

I already looked through Stack Overflow, and all the answers I could find were for .NET Framework. I wanted to see if there are more efficient ways to reuse code now, with ASP.NET Core.

Is using a Partial View or a View Component the most efficient method? Or is there another ASP.NET Core specific way to handle this?

CodePudding user response：

The best way to go about it is to use partial views!

https://docs.microsoft.com/en-us/aspnet/core/mvc/views/partial?view=aspnetcore-6.0

CodePudding user response：

Partial Views and View Components both allow you to centralize your views, and in that regard are interchangeable. Partial Views, however, exclusively contain view information (i.e., a cshtml file). By contrast, View Components additionally allow you to define preprocessing logic (similar to an [HttpGet] controller action).

Data Access and Parameterization

It's important to note that both Partial Views and View Components can have arguments or values passed into them.

• In a Partial View, this is done by relaying either a ViewDataDictionary or a custom view model to the Partial View (reference); this can be done using either the PartialAsync() HTML Helper or by using the <partial /> tag helper's model or view-data attributes.

• In a View Component, this is done by defining parameters on the InvokeAsync() method, and then relaying those as either an anonymous object via the InvokeAsync() HTML Helper or as attributes on the <vc:[view-component-name] /> tag helper.

As a result, both approaches can be parameterized and/or data bound, thus allowing them to be respond to the current state.

View Component Specific Capabilities

Where View Components distinguishes themselves is in that ability to define preprocessing logic via the InvokeAsync() method before returning a view model to the view, potentially including access to classes registered via dependency injection (e.g., via a composition root or a dependency injection container).

This is especially useful if your view needs to access data that's not (conveniently) available in the parent view—e.g., via a dependency, a database, or a webservice. So, for instance, if your view component is used by dozens of different views, but always needs access to similar data, this can allow you to centralize that logic so you don't need to look it up in each controller.

Examples: Given the ability to lookup data as part of a view component, I frequently use them for site navigation. That way, I don't need to lookup the navigation data in every single [HttpGet] action, nor include it in every single view model; it can be self-contained. Similarly, I use it for views containing common lookup data, such as dropdown boxes bound to data retrieved from an API or database call.

The Most Efficient Method

As far as which is most "efficient", that is a fairly subjective question, and not one we can answer without more information about your use case.

If a Partial View satisfies your needs, however, it is certainly the simplest and easiest approach: A View Component necessitates that an additional class be created and registered in order to support your view.

The question here, though, is likely less about efficiency and more about your requirements. If your view needs additional preprocessing to e.g. modify the view data, construct a new view model, or collect additional data, then you should use a View Component; otherwise, prefer a Partial View.

That said, given that you're looking to centralize the markup between a New and Edit view, I would expect a Partial View to satisfy your requirement. Both views will likely share an existing view and binding model, and the data populated will be specific to each view, therefore there likely isn't much need to centralize any pre-processing logic.

The one potential exception is if your New and Edit forms include lookup data—such as dropdown lists—sourced from a database. That said, as these views are almost certainly being returned from the same controller, you can easily centralize the lookup of that data in the controller itself, without needing to rely on a View Component to do that for you.