Was bedeutet "Core" im Kontext des Bibliotheksentwurfs?

Meiner Meinung nach bedeutet CORE etwas Unentbehrliches. Mathematische Funktionen und andere Funktionen mit Utility-Zwecken sind nicht im Kern. Sie sind eher "Utils".

Der Kern ist der Teil, der alles andere existiert - ohne ihn ergeben die anderen keinen Sinn. Andere Sachen, die nicht im Kern sind, können (nicht immer per Design möglich) entfernt werden.

Ich bat Bing , "Core" zu definieren. Eine der folgenden Definitionen war:

  

wesentlicher Teil: der zentrale oder die meisten   wichtiger Teil von etwas

Wenn also jemand einen Bibliothekskern benennt, ist dies der zentrale und wichtigste Teil seiner Anwendung und / oder seines Rahmens: -)

Ich verwende diese Konvention und es ist im Grunde eine Kernklassenbibliothek mit generischen Dienstprogrammklassen und Code, die wirklich keinen Platz in ihrer eigenen Bibliothek hat.

Zum Beispiel Erweiterungsmethoden für viele Klassen, zusätzliche mathematische Funktionen usw. Dinge, die nicht groß genug sind, um ein ganz anderes Projekt für sie zu rechtfertigen.

Was andere tun, habe ich keine Ahnung.

Ich sehe den Kern als das abstrakte Herz der Anwendung. Der Kern implementiert normalerweise genug Logik, um das Verhalten der gesamten Anwendung zu definieren.

Meines Erachtens sollten Datenzugriff und -präsentation nicht Teil des Kerns sein. Dadurch können sowohl Web- als auch Desktop-Anwendungen dasselbe Kernmodul nutzen.

In Ihrem Fall würde ich Geschäftslogik, Fehlerbehandlung und Konfiguration im Kernmodul enthalten.

Ich glaube auch, dass der Hauptgrund für ein großes Kernmodul darin besteht, die Kosten zu vermeiden, viele kleinere Module verwalten zu müssen.

Basierend auf den Antworten, die hier bereits gepostet wurden, gibt es offensichtlich keine "Standard" -Methode, um "Core" zu definieren, was die Entwicklung von Bibliotheken betrifft.

Ich würde mir also keine Sorgen machen, dass ich "korrekt" bin. Verwenden Sie den Begriff so, wie Sie es für richtig halten.

Dies wird wahrscheinlich als Häresie gewertet werden, aber nach einigen Jahren der Strukturierung von Lösungen mit getrennten Projekten für Datenzugriff, Geschäftslogik usw. werde ich diese Layer wahrscheinlich eher in ein einziges Projekt namens MyApp.Core schreiben Eine grundlegende Lösung würde nur aus dem Kernprojekt und einem UI-Projekt bestehen. Das heißt nicht, dass keine anderen Projekte jemals benötigt oder hinzugefügt würden (z. B. MyApp.Tests), sondern dass die grundlegende -Struktur auf diesen beiden basieren würde.

Bearbeiten: gekürzt pro Vorschlag in Kommentaren.

Ich sehe Kern als Voraussetzung für jede andere Bibliothek, die Sie möglicherweise von diesem Anbieter verwenden. Während also der Anbieter mehrere unabhängige Pakete anbietet, verlassen sich alle auf den Kern, um die Dinge zu erledigen. Andernfalls kann es zu schwerwiegender Codeverdopplung kommen.