What does "Core" mean in the Context of Library Design?

Question

I often see other developers naming libraries with "CORE". What does it actually mean?

Answer 1

I use that convention and it is basically a core class library with generic utility classes and code that really has no place in their own library.

For instance, extension methods to a lot of classes, extra math functions, etc. Things that aren't big enough to warrant a whole other project for them.

What others do I have no idea though.

Answer 2

I asked Bing to define "Core". One of the definitions it came up with was:

essential part: the central or most important part of something

So basically, when someone names a library core, it is the central and most important part of their application and/or framework :-)

Answer 3

In my opinion, CORE means something indispensable. Math functions and other functions with utility purposes are not in the core. They are rather "Utils".

The core is that part that makes everything else exist - without it, the others make no sense. Other stuff, that is not in the core can (not always possible by design) to be removed.

Answer 4

I view the core as the the abstract heart of the application. The core typically implements enough logic to define the behavior of the whole application.

So in my view data access and presentation should not be part of core. This allows both web and desktop applications to share the same core module.

In your case I would have contain business logic, error handling and configuration in the core module.

I also belive that the main reason for having a big core module is to avoid the cost of having to maintain a lot of smaller modules.

Answer 5

I see core as a prerequisite for any other library that you may use from that vendor. So, while the vendor may offer several independent packages, they all rely on core to get things done. Otherwise it may result in severe code duplication.

Answer 6

This will probably be judged as heresy, but after several years of structuring solutions with separate projects for data access, business logic, etc, I am more likely going forward to put those layers into a single project called MyApp.Core so that a basic solution would consist of only the core project and a UI project. That's not to say no other projects would ever be needed or added (e.g. MyApp.Tests), but that the basic structure would be based on those two.

Edit: abridged per suggestion in comments.

Answer 7

Based on the answers already posted here, apparently there is no "standard" way of defining "Core" as it relates to developing libraries.

So I wouldn't worry about being "correct." Use the term as you see fit.