CODEWITHSUNDEEP
c#asp.net-core-mvc
Jason Hopp
Jason Hopp

Reputation: 13

Using the ASP.NET MVC framework to create generalized framework for multiple similar sites

I have a fairly high level design question. I'd like to come up with a framework for creating multiple very similar ASP.NET MVC sites.

These sites would be for selling various consumer goods, with each goods category having its own site (this requirement is fixed). Different category sites would mostly be quite similar - essentially a series of static pages that allow drilling down into various subcategories to view product listings, with some simple forms for expressing interest in a listing (for example).

However, it's vague at this point exactly how similar these sites might be, so I need a degree of flexibility

I come from a React background- so my vague initial thought is that the best way to approach this would be creating a library of common components used across the sites - these would range from fairly low level ones for, for example, a table of specifications, to higher level ones that might cover an entire page. The library consumer could pass in the specific apis used for the components/other specific data. I don't have much experience with the ASP.NET MVC framework, so I'm not yet certain exactly how that would work.

My question is: does this sound like I'm on the right track with this approach?

Any alternate suggestions? Also, are there any particular ASP.NET MVC features that would be key to an approach like this? (Not sure yet whether I'd use the older .NET Framework MVC, or .NET Core- any features of either that would favor one or the other for this?)

Thanks so much for your time, I appreciate the help!

Upvotes: 1

Views: 181

Answers (2)

Chris Pratt
Chris Pratt

Reputation: 239290

There's frankly all kinds of ways to do this, and you may choose one, some, or all. For common classes (entities, helpers, etc.) you can create class library projects. You can also share controller code this way as well. Making smart use of generics will allow you reuse greater amounts of code. Sharing views is a bit more complicated, but there are ways to do that, such as RazorGenerator or NuGet packages. NuGet packages should be used to share static resources, as well, such as images, JavaScript, stylesheets, etc. Alternatively, you can host these on a CDN or other centralized area and reference them from there (use configuration to set path/URL, so you don't hardcode static paths all over the place).

As far as framework choice goes, ASP.NET Core provide a bit more than MVC in the code reuse category. You can create custom middleware, view components, tag helpers, etc. ASP.NET MVC has somewhat similar capabilities (HTTP modules, child actions, and HTML helpers), but it's arguably a bit more difficult to reuse those components/create them in the first place. Other than that, though, choice of framework really doesn't matter.

Upvotes: 1

n4feng
n4feng

Reputation: 2454

As the Definition of MVC, what you say that "creating a library of common components used across the sites" are content in the model and controller part. MVC has nothing special from other OOP approaches, but just specify that you are going to divide your abstract classes into three different category: Model (which define the container of data), View (which define the appearance of the program) and Controller (which define the behaviour of the program).

MVC is just a pattern but not a technology. For example one of the web-application I worked on in the company, the MVC structure followed as: ExtJs frontend (it has it's own controller written in javascript to call our API, therefore all itself could already be called as a "MVC" program), C# API server backend which linked back to our database (both Oracle and Microsoft SQL). As you can see, all of these components can be replaced by something else (for instance, you can use Angular2 replace ExtJs, you can use java or php replace the C# API server, and so on).

Upvotes: 0

Related Questions