DEV Community: Dennis Hering

Your Framework Is Replaceable. Your Architecture Is Not.

Dennis Hering — Sat, 07 Feb 2026 15:05:36 +0000

Frameworks are transient by nature.

They emerge, gain traction, dominate discussions for a few years, and are eventually replaced or fundamentally reworked. This is not a flaw of frontend development; it is a natural consequence of rapid innovation in tooling, browsers, and developer expectations.

The mistake many teams make is not choosing the “wrong” framework, but assuming that the framework they choose today will still shape their codebase in the same way tomorrow.

What should remain stable over time is not the framework, but the business logic of an application: the rules, validations, workflows, and constraints that represent real-world requirements.

Unfortunately, in many frontend projects, these two concerns are tightly intertwined.

When Frameworks Become Architecture

In theory, a framework is just a tool.
In practice, it often becomes the architecture.

Business rules are implemented inside components.
Validation logic depends on framework-specific reactivity models. Application workflows are bound to lifecycle hooks and UI state.

At first, this feels efficient. Everything is close together. The mental overhead is low, and progress is fast. But this efficiency is deceptive.

Over time, the framework stops being a replaceable detail and starts defining how the system works at its core. At that point, changing the framework is no longer a UI problem — it is a fundamental rewrite.

The Long-Term Cost of Coupling

Framework coupling rarely hurts in the short term.
It hurts later, when the context has changed.

Teams encounter the problem when they try to:

migrate to a new framework version
introduce a second UI (for example, mobile or desktop)
reuse logic in a different environment
improve test coverage in a meaningful way

What they discover is that business logic cannot be extracted without also pulling in framework concepts. Tests require component rendering, lifecycle simulation, and extensive mocking. Small changes ripple through the UI layer, even when the underlying rules remain unchanged.

This is not a technical limitation.
It is an architectural decision that was made implicitly, often without being discussed.

Separate What Changes from What Must Endure

A useful architectural principle is to separate concerns based on their expected rate of change.

Frameworks change quickly.
Business rules change slowly.

UI paradigms evolve.
Domain concepts tend to persist.

This leads to a simple but powerful guideline:
The UI layer coordinates. The domain layer decides.

The responsibility of the UI is to handle user interaction and presentation. It gathers input, invokes application logic, and renders outcomes. It should not contain rules about what is valid, what is allowed, or what must happen next.

Those decisions belong to code that does not depend on any UI technology.

Example (Pseudo Code): UI Orchestrates, Domain Decides

The core idea is that the UI layer should not contain rules, workflows, or side effects. It should only coordinate user interaction.

Bad Way: Mixed concerns (UI + domain + side effects)

// UI component (framework code)
component CheckoutForm {
  state email = ""

  onSubmit() {
    if not email.contains("@") {
      showError("Invalid email")
      return
    }

    response = http.post("/checkout", { email })

    if response.ok {
      navigate("/success")
    } else {
      showError("Checkout failed")
    }
  }

  render() { ... }
}

This looks harmless. But now your validation rules and checkout workflow are locked into:

component lifecycle
framework state management
UI-level error handling

Reusing or testing the logic requires the framework to be present.

Right Way: Separated concerns (domain + application logic independent of UI)

// Domain / application layer (plain code, no framework)
function validateEmail(email): Result {
  if email is empty -> return Error("Email is required")
  if not email.contains("@") -> return Error("Invalid email")
  return Ok()
}

async function submitCheckout(email, httpClient): Result {
  validation = validateEmail(email)
  if validation is Error -> return validation

  response = await httpClient.post("/checkout", { email })
  if not response.ok -> return Error("Checkout failed")

  return Ok()
}

// UI component (framework code)
component CheckoutForm {
  state email = ""
  state error = null
  state loading = false

  onSubmit() {
    loading = true
    error = null

    result = await submitCheckout(email, http)

    loading = false

    if result is Error {
      error = result.message
    } else {
      navigate("/success")
    }
  }

  render() { ... }
}

The "domain" functions are now:

callable from anywhere (UI, CLI, background jobs, tests)
testable without rendering a component
reusable even if the UI framework changes

The UI stays slim and replaceable.

Why This Is Not Overengineering

This kind of separation is sometimes dismissed as theoretical or excessive, especially in frontend development. That criticism usually comes from projects that have not yet lived long enough to feel the consequences.
The separation does not require complex patterns or heavy abstractions. It requires discipline in deciding where logic lives.
Plain functions that implement validation, workflows, and side effects can exist without any knowledge of the framework. The UI becomes a thin adapter that translates user actions into function calls and renders the result.
This approach scales down as well as up. It is just as useful for small applications as it is for large ones.

Testability Is a Side Effect, Not the Goal

One immediate benefit of this separation is testability, but it is not the primary reason to do it.
When core logic is independent of the UI, it can be tested without rendering components, without simulating user interaction, and without bootstrapping a framework runtime. Tests become faster and more focused. Failures are easier to diagnose.
More importantly, tests begin to reflect business behavior, not UI mechanics. That shift alone improves code quality.

Framework Evolution Is Not Incremental

A common assumption is that framework upgrades are mostly incremental. In reality, frameworks often change their mental models.
Angular illustrates this clearly.
Within a relatively short timeframe, teams moved from Angular 14-era patterns dominated by Observables, RxJS pipelines, and NgRx-driven state management to a landscape where Angular 21 promotes Signals as a core reactivity primitive. This is not a cosmetic change. It affects how state is represented, how dependencies are tracked, and how updates propagate through the system.
Applications that embedded business logic deeply into these framework-specific paradigms faced significant refactoring pressure - even when the actual business requirements remained unchanged.
The lesson is not that Angular is unstable. The lesson is that frameworks evolve faster than business logic.

Architecture as Risk Management

Architecture is often discussed in terms of elegance or purity. In practice, it is about risk management.
A codebase where business logic is framework-agnostic has:

lower migration risk
lower refactoring cost
a longer useful lifespan

The goal is not to predict the future, but to avoid unnecessary constraints. When the framework changes direction - and it will - you want that change to be localized, not systemic.

Frameworks Are Replaceable by Design

Framework authors know their tools will evolve. That is why APIs change, paradigms shift, and new abstractions are introduced. Expecting a framework to remain stable for a decade is unrealistic.
What can remain stable is your understanding of the domain and the rules that govern it.
Treating frameworks as replaceable details is not an academic exercise. It is a pragmatic response to the reality of modern software development.

A Question Worth Taking Seriously

If you were forced to replace your frontend framework in five years:

Which parts of your system would survive unchanged?
Which parts would need to be rewritten from scratch?

If the answer is "almost everything needs to be rewritten," then the framework is not just a tool - it has become your architecture.

And that is a choice worth reconsidering.

Why Composition over Inheritance Is More Than Just a Design Principle

Dennis Hering — Sat, 21 Jun 2025 11:45:31 +0000

In many codebases, inheritance is still the default tool for reusing behavior. But in real-world, evolving systems, inheritance often brings more rigidity than flexibility. Composition offers a significantly more adaptable and maintainable alternative.

Where Inheritance Falls Short

Inheritance implies an “is-a” relationship between objects. While this seems clean in theory, it quickly leads to practical problems:

Rigid hierarchies: Behavior is locked into base classes and difficult to adjust without side effects.
Tight coupling: Subclasses depend heavily on base classes. A small change in the base can ripple through the system.
Low reusability: Behavior is tied to a particular class hierarchy and hard to extract or share.
Poor maintainability: Deep inheritance trees obscure behavior and make debugging harder.

Composition as a Practical Solution

With composition, behavior is not inherited but injected at runtime. This approach brings several concrete benefits:

Modularity: Components are clearly separated and can be reused independently.
Loose coupling: Classes depend on abstractions (e.g., interfaces), not implementations.
Flexibility: Behaviors can be combined or swapped dynamically.
Testability: Components are easily mocked or isolated in unit tests.

Example: Multi-Channel Notification Service in .NET

Instead of building an inheritance chain like EmailNotificationService, SmsNotificationService, and MultiChannelNotificationService, we model each channel as a behavior and inject them via composition:


public interface INotificationChannel
{
    void Send(string message);
}

public class EmailChannel : INotificationChannel
{
    public void Send(string message) =>
        Console.WriteLine($"Sending Email: {message}");
}

public class SmsChannel : INotificationChannel
{
    public void Send(string message) =>
        Console.WriteLine($"Sending SMS: {message}");
}

public class NotificationService
{
    private readonly IEnumerable<INotificationChannel> _channels;

    public NotificationService(IEnumerable<INotificationChannel> channels)
    {
        _channels = channels;
    }

    public void Notify(string message)
    {
        foreach (var channel in _channels)
            channel.Send(message);
    }
}

// Usage
var service = new NotificationService(new[]
{
    new EmailChannel(),
    new SmsChannel()
});

service.Notify("System update available.");

This setup allows you to mix and match any number of channels without subclassing, without fragile overrides, and without bloating your class hierarchy.

Conclusion

Composition isn’t just a theoretical ideal — it’s a practical, robust tool. Especially in modern .NET applications, where interfaces, dependency injection, and modular design are the norm, composition often leads to simpler, more maintainable code.

Inheritance still has its use cases. But when designing for flexibility, reusability, and testability, think in components — not class trees.

Ionic: Angular 18, CapacitorJS & SQLite

Dennis Hering — Mon, 25 Nov 2024 11:32:34 +0000

SQLite Integration in an Angular 18 Standalone Application and CapacitorJS

This tutorial explains how to integrate SQLite into an Angular 18 application that uses standalone components and Signals. We will use the @capacitor-community/sqlite plugin to enable SQLite functionality for both Android and iOS platforms.

Prerequisites

Ensure you have the following installed:

Node.js and npm
CapacitorJS
Angular 18 with standalone components and Signals

Step 1: Install Required Packages

Run the following commands to install the necessary dependencies:

npm install @capacitor-community/sqlite
npx cap sync

These commands install the SQLite plugin and synchronize the changes with the native platforms.

Step 2: Create a Database Service

The database logic will be encapsulated in a service for better maintainability.

// src/app/services/database.service.ts
import { Injectable } from '@angular/core';
import { CapacitorSQLite, SQLiteConnection, SQLiteDBConnection } from '@capacitor-community/sqlite';

@Injectable({
  providedIn: 'root',
})
export class DatabaseService {
  private sqlite: SQLiteConnection;
  private db: SQLiteDBConnection | null = null;

  constructor() {
    this.sqlite = new SQLiteConnection(CapacitorSQLite);
  }

  async initializeDatabase(): Promise<void> {
    try {
      // Check connection consistency
      const retCC = (await this.sqlite.checkConnectionsConsistency()).result;

      // Check is connected
      const isConnection = (await this.sqlite.isConnection('appDB', false)).result;

      if (!isConnection && !retCC) {
        // Create a new connection
        this.db = await this.sqlite.createConnection('appDB', false, 'no-encryption', 1, false);
        await this.db.open();
        await this.createTables();
      } else {
        // Retrieve existing connection
        this.db = await this.sqlite.retrieveConnection('appDB', false);
        await this.db.open();
      }
    } catch (error) {
      console.error('Error initializing the database:', error);
    }
  }

  private async createTables(): Promise<void> {
    if (!this.db) throw new Error('Database connection is not open');
    const createTableQuery = `
      CREATE TABLE IF NOT EXISTS users (
        id INTEGER PRIMARY KEY AUTOINCREMENT,
        name TEXT NOT NULL,
        age INTEGER NOT NULL
      );
    `;
    await this.db.execute(createTableQuery);
  }

  async addUser(name: string, age: number): Promise<void> {
    if (!this.db) throw new Error('Database connection is not open');
    const insertQuery = `INSERT INTO users (name, age) VALUES (?, ?);`;
    await this.db.run(insertQuery, [name, age]);
  }

  async getUsers(): Promise<any[]> {
    if (!this.db) throw new Error('Database connection is not open');
    const result = await this.db.query('SELECT * FROM users;');
    return result.values || [];
  }

  async closeDatabase(): Promise<void> {
    if (this.db) {
      await this.sqlite.closeConnection('appDB');
      this.db = null;
    }
  }
}

Step 3: Initialize the Database Service in the Root Component

In the root component of your application, initialize the DatabaseService.

// src/app/app.component.ts
import { Component, OnInit } from '@angular/core';
import { DatabaseService } from './services/database.service';

@Component({
  selector: 'app-root',
  templateUrl: './app.component.html',
})
export class AppComponent implements OnDestroy, AfterViewInit {
  constructor(private databaseService: DatabaseService) {}

  // Important: Initialize the database connection when the component is created  
  async ngAfterViewInit() {
    await this.databaseService.initializeDatabase();
  }

  // Important: Close the database connection when the component is destroyed
  async ngOnDestroy() {
    await this.databaseService.closeDatabase();
  }
}

Step 4: Use the Database Service in a Component

You can now use the DatabaseService in any component to perform CRUD operations.

// src/app/components/user-list/user-list.component.ts
import { Component, OnInit } from '@angular/core';
import { DatabaseService } from '../../services/database.service';

@Component({
  selector: 'app-user-list',
  templateUrl: './user-list.component.html',
})
export class UserListComponent implements OnInit {
  users: any[] = [];

  constructor(private databaseService: DatabaseService) {}

  async ngOnInit() {
    await this.databaseService.addUser('Max Mustermann', 25);
    await this.databaseService.addUser('Erika Musterfrau', 30);
    this.users = await this.databaseService.getUsers();
  }
}

Notes

Connection Consistency: Ensure you check the connection consistency using checkConnectionsConsistency() to avoid duplicate connection errors.
Singleton Service: Use Angular's @Injectable with providedIn: 'root' to ensure that DatabaseService is a singleton.
Test on Both Platforms: Always test your implementation on both Android and iOS devices.

Conclusion

With these steps, you have successfully integrated SQLite into your Angular 18 standalone application with CapacitorJS. This implementation ensures connection consistency and encapsulates database operations in a reusable service.

Angular 19: linkedSignal & Resource API

Dennis Hering — Tue, 12 Nov 2024 10:18:09 +0000

Angular 19 introduces two significant features aimed at enhancing reactive programming and data management within Angular applications: the linkedSignal function and the Resource API. These additions address existing challenges in state synchronization and asynchronous data handling, providing developers with more streamlined and efficient tools.

linkedSignal: Enhanced Signal Management

In previous Angular versions, managing state that depended on other signals often required complex workarounds. Developers typically used computed() signals to derive values based on other signals. However, computed() signals are read-only, limiting flexibility when a writable signal was needed that could both depend on other signals and be updated independently.

The linkedSignal function resolves this issue by creating a writable signal that automatically updates its value based on changes in a source signal. This functionality simplifies the synchronization between signals and facilitates the implementation of reset patterns, leading to more maintainable and predictable state management.

Example:

import { signal, linkedSignal } from '@angular/core';

const sourceSignal = signal(0);
const updatedSignal = linkedSignal({
  source: sourceSignal,
  computation: () => sourceSignal() * 5,
});

In this example, updatedSignal will always be five times the value of sourceSignal and will automatically adjust as sourceSignal changes.

Addressing Existing Challenges:

Before the introduction of linkedSignal, developers faced difficulties in creating signals that were both dependent on other signals and writable. This often led to convoluted code structures and increased the potential for errors. By providing a straightforward method to create such signals, linkedSignal enhances code clarity and reduces the likelihood of bugs related to state management.

Resource API: Streamlined Data Loading

Managing asynchronous data loading, especially through HTTP requests, has been a complex task in Angular applications. Developers needed to handle various states of data fetching manually, including loading, success, and error states, which often resulted in verbose and error-prone code.

The Resource API in Angular 19 offers a reactive approach to loading resources, particularly for read operations like HTTP GET requests. It allows developers to define a loader function that asynchronously fetches data and provides signals to monitor the current status and handle errors effectively.

Example:

import { resource } from '@angular/core';

const productResource = resource({
  loader: async () => {
    const response = await fetch('https://api.example.com/products');
    return response.json();
  }
});

In this example, productResource is initialized with a loader function that fetches data from the specified API. The Resource API manages the loading state and any potential errors, simplifying the data fetching process.

Key Features of the Resource API:

Status Tracking: Signals such as status, error, and isLoading allow developers to monitor the current state of the data loading process, facilitating better user feedback and error handling. The status signal can have the following values:
- Idle (0): The resource is in its initial state and has not started loading.
- Error (1): An error occurred during the loading process.
- Loading (2): The resource is currently loading data.
- Reloading (3): The resource is reloading data, typically after a previous load.
- Resolved (4): The resource has successfully loaded data.
- Local (5): The resource's data has been updated locally without a new load.
Local Updates: The update method enables local modifications to the loaded data without triggering a new loading process, providing flexibility in data manipulation.
Request Management: The Resource API automatically restarts the loading process when dependent signals change and can cancel ongoing requests to prevent race conditions, ensuring data consistency and integrity.

Addressing Existing Challenges:

Prior to the Resource API, developers had to implement manual logic to handle various states of data fetching, leading to increased complexity and potential for errors. The Resource API abstracts these concerns, offering a declarative and concise way to manage asynchronous data operations, thereby reducing boilerplate code and improving application reliability.

Conclusion

The introduction of linkedSignal and the Resource API in Angular 19 represents significant advancements in reactive programming and data management. These features address longstanding challenges by providing developers with more flexible, efficient, and maintainable tools for state synchronization and asynchronous data handling. By leveraging these new capabilities, developers can create modern web applications with enhanced performance and user experience.