A Tale of Two APIs
A strategy for dealing with multiple public interfaces for libraries.
When developing libraries it occasionally becomes necessary to expose a different public interface to different groups of users. The most common scenario is one in which your library needs to be accessed in one way by applications that use it, but another way by other libraries that extend it. You want extension developers to have access to all the behind-the-scenes details, but exposing those properties and methods to applications would be confusing or even damaging by promoting improper use. In other words, you want the internal properties and methods to be exposed to one set of developers but not another. In this post I'll examine a strategy for exposing different public APIs to different sets of users.
open source (18)
ASP.NET (15)
ASP.NET MVC (14)
static site generator (9)
programming (8)
Azure (7)
Wyam (7)
Roslyn (7)
NuGet (6)
devops (5)
.NET Compiler Platform (5)
Razor (4)
personal (4)
Vue.js (4)
Entity Framework (4)
LINQ (4)
database (4)
KendoUI (4)
KendoUI MVC (4)
grid (4)
csharp (3)
scripting (3)
meta (3)
T4 (3)
XML (3)
Mono (3)
GtkSharp (3)
tools (2)
Cake (2)
msbuild (2)
magic strings (2)
Azure Cosmos DB (2)
Azure Functions (2)
LINQ to Entities (2)
strings (2)
algorithms (2)
LINQPad (2)
blog (2)
CSS (2)
export (2)
CSV (2)
HtmlHelper (2)
Entity Framework Code First (2)
Nxdb (2)
XQuery (2)
Blazor (1)
WebAssembly (1)
Netlify (1)
FTP (1)
documentation (1)
configuration (1)
DSL (1)
enum (1)
stdin (1)
stream (1)
console (1)
cli (1)
npm (1)
node (1)
microdependencies (1)
collections (1)
concurrent (1)
HashSet (1)
Twitter (1)
Serilog (1)
MiniProfiler (1)
logging (1)
OWIN (1)
templating (1)
design (1)
web (1)
JavaScript (1)
API (1)
IIS (1)
debugging (1)
LINQ to SQL (1)
FluentBootstrap (1)
Bootstrap (1)
RazorDatabase (1)
GitHub (1)
AppVeyor (1)
fluent interfaces (1)
method chaining (1)
style (1)
conventions (1)
PDF (1)
Acrobat (1)
Excel (1)
checkbox (1)
postback (1)
icon fonts (1)
icons (1)
SQL (1)
SQL Server (1)
round robin (1)
DotNet (1)
Dictionary (1)
MultiDictionary (1)
data annotations (1)
persistence (1)
object persistence (1)
NiceThreads (1)
Threading (1)
Monitor (1)
ReaderWriterLockSlim (1)
locking (1)
ILocker (1)
networkdays (1)
weekdays (1)
ButtonPressEvent (1)
Context Menu (1)
ContextMenuHelper (1)
Menu (1)
Popup (1)
Popup Menu (1)
CellRenderer (1)
TreeModel (1)
TreeView (1)
TreeViewColumn (1)