1

I am wondering if this is a good idea in the first place.

Basically I want to create a template upon which to build numerous sites. The idea is I can update the "core" of the website without having to change much, if at all, any application specific code.

This way, if there is a flaw in the core of one web server I can update all other webservers by simply modifying the core code.

The core code I was thinking would be a class library. Certain controller and db logic that is common to all my websites could sit in separate libraries. Each new MVC project will then reference those libraries and build on top of them.

Is this a good practice? Would it be worth the extra effort, or should I simply copy and paste the common code between projects?

5
  • 4
    Writing software libraries that contain common functionality is a very effective and well-established technique. Nov 9, 2017 at 15:50
  • why would you think it not a good idea?
    – Ewan
    Nov 9, 2017 at 16:26
  • Specifically pertaining to ASP.NET MVC I thought maybe the rules might vary. Or Microsoft implemented their own techniques more suited for their framework. Nov 9, 2017 at 17:06
  • If you copy and paste the common code between projects, what happens when you eventually decide you want to change that common code (e.g. to fix a bug, or to fulfil some new requirement in the future)? Nov 9, 2017 at 21:42
  • Agreed. Exactly why I was wondering if this was the right route to go in the first place. So I will say it is highly recommended to use a common class library for my MVC projects where frequently used and common code is involved. Nov 9, 2017 at 23:27

1 Answer 1

1

Yes, writing libraries with common code is good practice. While copy/paste might save you some work initially, you are almost guaranteed to pay for it later, because the moment you need to make any modifications to the common code, you need to remember all the places its been copy/pasted. Furthermore, if someone else assumes the responsibility of maintaining these applications in the future, they will also need to know where all the duplicate code is located.

The common approach that I've seen in practice (in .NET) has been to package common code as Nuget libraries and serve them from your own Nuget server. However, in my experience there are some drawbacks that you should be aware of when you start creating common libraries for multiple applications. For example, some developers tend to forget the overhead of maintaining multiple versions of these common libraries. Unless you are planning to update all your applications to the newest version of your library as soon as you release it (which is unlikely), you will have to maintain several versions of your library for backwards compatibility, especially if you introduce breaking changes.

Likewise, If you are the only one producing and consuming these libraries as your question indicates, you should also be very careful when deciding what you consider "common" code and how those libraries are being consumed. If you find yourself modifying a common code library because a single application that consumes it requires the change, that code is probably not common. Initially, as a rule of thumb, I would create libraries for cross-cutting concerns such as logging, monitoring, and error handling which are obviously common to your applications. Its almost always easier to refactor code into a library than to break a dependency on a library that turns out not to be so common.

As the producer and the consumer of your libraries, you run the risk of tightly coupling your consumers to the implementation of the library. You also run the risk of making your library interfaces consumer specific, rather than generic. Try to consume your libraries using a common approach throughout all your applications. At the very least, you should be trying to create an "anti-corruption" layer of abstraction between your application and the code that consumes the library.

For example, if you are using an OWIN Pipeline in an ASP.NET MVC application, you can inject your common code as Middleware, which would separate the consumption of these libraries from the code that implements the business logic in your application. If you are unable to deprecate a common library or modify its public interface without requiring modifications to business logic in your application, I would argue that you are consuming it incorrectly. Likewise, when creating a public interface for your library, make sure it can be consumed from any application.

If its not obvious by my answer so far, creating common libraries to share between applications is not as simple as grouping duplicate code. Its likely that you will get this wrong the first time you try it (I know I did) and they will be some painful lessons. Don't let that discourage you though, in my experience, the growing pains were well worth the benefits.

Before heading down this path, I would suggest you learn more about the topic. One good place to start (for .NET) is Microsoft's Framework Design Guidelines:

https://docs.microsoft.com/en-us/dotnet/standard/design-guidelines/index

There are also a number of good books written on this topic.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.