DEV Community: ThatGhost

Result is not error handling

ThatGhost — Sun, 12 Apr 2026 19:14:58 +0000

We talk about the Result pattern like it's a better way to handle errors. Return a Result instead of throwing an exception, wrap your failure cases, done. That framing is not wrong, but it undersells what Result actually is.

Result is a flow control tool. Error handling is just a side effect.

The problem with raw returns and exceptions

When a service returns a raw value or throws on failure, the caller owns the failure logic. Every caller. That means domain knowledge — what "not found" means, what "invalid state" means — leaks upward into code that shouldn't care about it.

Exceptions make this worse because they're invisible in the signature. Nothing in this tells you what can go wrong:

Task<User> GetByIdAsync(int id);

You have to read the implementation, or get surprised at runtime.

Result as a communication contract

The shift is treating success and failure as equally valid outcomes, both visible in the signature, both something the caller can reason about without reading the implementation.

public interface IUserService
{
    Task<Result<User>> GetByIdAsync(int id);
    Task<Result> DeleteAsync(int id);
}

You already know what this service can tell you. You don't need to hunt for thrown exceptions or check for nulls. The contract is in the signature.

The chain

Where Result earns its keep is in composition. Once your services all speak the same language, you can pipeline them:

public async Task<Result> AnonymizeAsync(int userId)
{
    return await _userService.GetByIdAsync(userId)
        .ThenAsync(user => _anonymizationService.AnonymizeAsync(user))
        .ThenAsync(user => _emailService.SendConfirmationAsync(user));
}

Three services. No if/else. No try/catch. If any step fails, the failure propagates, and the rest of the chain doesn't execute. The happy path and the failure path are both readable in the same six lines.

This is the thing most explanations of Result miss. It's not just cleaner error handling. It's a way to express a multi-step flow as a single readable unit.

The controversial claim

Exceptions should be for things you didn't plan for. Infrastructure failures. Bugs. Things that represent a broken assumption about the world.

If/else branching in service code is a smell. It means the caller is making decisions that belong to the callee, or that flow logic is scattered across layers instead of being composed in one place.

Result is the third option. And once you start using it consistently, it should be your default return type for anything that can meaningfully fail.

Failure is composable too

Here's where it gets interesting. Because failure is a first-class value, you can do logic on it.

In a transactional flow, a failure mid-chain isn't just something to report — it's something to act on. You can inspect the error, trigger compensating logic, revert what's already happened, and still return a clean Result to the caller. The failure path is as composable as the success path.

public async Task<Result> ProcessAsync(Order order)
{
    var result = await _paymentService.ChargeAsync(order)
        .ThenAsync(payment => _inventoryService.ReserveAsync(order));

    if (result.IsFailure)
        await _paymentService.RefundAsync(order);

    return result;
}

No exception handler. No special casing. Just a Result you can inspect and act on like any other value.

The connective tissue

In the previous posts in this series we established what your classes are — Services, Providers, Mutators — and how they relate through DI rather than inheritance. Result is what makes that system actually work at runtime.

Without a shared communication contract, a flat graph of injected services is just a naming convention. With Result, every class in the graph speaks the same language. Flow is explicit. Failure is visible. And the whole thing stays readable without exceptions leaking through layers or if/else logic colonizing your service code.

The AI Should Touch the Layout, Let Your Endpoints Do the Rest

ThatGhost — Wed, 08 Apr 2026 11:39:47 +0000

We've been building a dashboarding app at work. It looks great. The design is solid, the components are polished, and every time we show it to a stakeholder they love it.

It also takes forever to wire up.

Every new view is the same cycle: a stakeholder wants to see something, a developer builds an endpoint, another developer connects it to a component, someone tweaks the layout, and three days later the stakeholder sees the thing they asked for a week ago. Multiply that by every team, every quarter, every "can we just add one more metric" request, and you start to feel like you're running a custom dashboard factory instead of building a product.

We knew the components were good. The problem was the wiring.

The obvious AI answer is wrong

The first instinct is to let the AI query your database. Natural language to SQL, job done. Except it isn't.

You get hallucinated joins, filters that look right but produce wrong aggregates, and a model that has been handed direct access to your production data with nothing structural stopping it from being manipulated by whatever it reads along the way. And when something goes wrong — when a number is off, when a report looks plausible but isn't — you have no audit trail. Every query was generated fresh. Nothing is stable or reviewable.

The deeper problem is that this gives the AI the wrong job. The AI is good at understanding intent and composing structure. It is not a trustworthy query engine, and treating it like one trades one wiring problem for a much worse one.

The insight: the AI should touch the layout, not the data

What if the AI never saw your data at all?

Instead of asking the AI to fetch data, you ask it to decide what to show and where to show it — and then let your existing, validated endpoints do the actual fetching. The AI produces a layout manifest. The client executes it.

The flow looks like this. When a user submits a query, a vector search runs against a store of pre-registered endpoint descriptions and retrieves the semantically relevant subset. That subset, combined with a static component registry, gets injected into the AI context. The AI reasons about intent, selects components, computes any derived values like date ranges, assigns a bento-grid layout, and outputs a JSON document — the UI Manifest. No data flows through the AI at any point. It only ever sees descriptions of what endpoints exist, not what they return.

The client receives the manifest, renders the component shells, and each component independently fetches its own data from the URL the AI specified. Standard HTTP calls, standard backend validation, standard response handling. The data pipeline is completely unchanged. The AI just decided what to ask for and where to put it.

The registry is the trust boundary

The component registry is a static list the development team maintains. Each entry defines a component name, the data type it accepts — one of Metric, Dataset, or List — and the minimum column span it requires in the 12-column grid. The AI can only reference components that exist in that list. It cannot invent a component. It cannot reference an endpoint that has not been registered.

{
  "component_registry": [
    { "name": "LineChart", "accepts": "Dataset", "minCol": 6 },
    { "name": "StatCard",  "accepts": "Metric",  "minCol": 3 },
    { "name": "DataTable", "accepts": "List",     "minCol": 12 }
  ]
}

This is an intentional bottleneck. Every component in the registry has been built and tested by the team. Every endpoint has been written, validated, and registered with a parameter schema. The backend validates all parameters on every request before executing anything — the AI constructs a URL, the backend decides whether it is valid, and the data only moves if it passes that gate.

What you end up with is a system where the AI operates inside a box your team defines. Prompt injection in a user query cannot cause the AI to call an unregistered endpoint — it is not in context and would fail backend validation if constructed. The AI cannot see raw table names, schema details, or connection strings. There is nothing to exfiltrate during the generation phase because there is no data in the generation phase.

The registry is not just a config file. It is the security model.

What this actually produces

For a query like "show me sales versus targets from last week", the AI calculates the date range, selects a LineChart for the trend and a StatCard for the total, assigns the chart most of the grid width because it is the primary insight, and outputs:

{
  "dashboardTitle": "Weekly Performance Overview",
  "blocks": [
    {
      "component": "StatCard",
      "gridSettings": { "colSpan": 4, "rowSpan": 1 },
      "title": "Total Revenue",
      "dataUrl": "/api/sales/total-revenue?startDate=2026-03-30&endDate=2026-04-05"
    },
    {
      "component": "LineChart",
      "gridSettings": { "colSpan": 8, "rowSpan": 2 },
      "title": "Sales vs Target Trend",
      "dataUrl": "/api/sales/weekly-trend?startDate=2026-03-30&endDate=2026-04-05"
    }
  ]
}

The client renders two component shells. Each fetches its own data independently. The dashboard appears. The AI never saw a single revenue figure — it just decided where to put the boxes and which endpoints to point them at.

Each endpoint returns data in one of the three standardized payload types. A Metric is a scalar value with an optional delta. A Dataset is columnar data with named columns and rows. A List is a collection of typed records. Components know how to render their payload type. The manifest connects them. That standardization is also what makes the whole thing framework-agnostic — Blazor, React, Angular, and Vue all just need to implement the same three renderers and a manifest parser. The AI logic and the endpoint layer are completely shared.

The side effect: user-generated dashboards for free

Once you have a manifest, you have a JSON blob. And a JSON blob can be saved.

When a user likes what the AI built, they save the manifest. It becomes a named, persistent dashboard — no SQL knowledge required, no developer involved, no custom view built on request. The saved artifact is a pointer to endpoints your team already validated, with a layout attached. It is versionable, shareable, and auditable in the same way any other application data is. It is not an opaque generated query sitting in someone's personal schema.

This is what changes the relationship between business users and data-heavy software. The gap has never been the data. The gap has been the translation layer between "I want to know X" and "here is X, rendered clearly." That translation has historically required a developer. This pattern removes that requirement without removing developer control over what is expressible.

Where this goes

The immediate application is dashboards, but the pattern is general. Any application with a curated component library and a set of validated endpoints can adopt it. The AI becomes a translator between user intent and application capability, bounded by whatever the development team chose to expose.

And at the broadest level, this is what AI in enterprise software should look like. Not an autonomous agent with broad data access, but an orchestration layer that makes existing, validated capabilities accessible to anyone who can ask a question. The organization controls what is inside the box. The AI makes the box useful to everyone.

We did not set out to design a pattern. We just wanted to stop spending three days on every dashboard request. But the solution we landed on turns out to generalize cleanly, and it solves a problem a lot of teams are going to run into as they try to add AI to software that handles real data.

The AI should not talk to your data. It should talk to your layout. Let your endpoints do the rest.

There Is No Such Thing As a Service

ThatGhost — Wed, 01 Apr 2026 08:36:36 +0000

If you have been following this series, you know I am a fan of services. Dependency injection, single responsibility, clean boundaries between concerns. Done right, you end up with hundreds of services, each doing exactly one thing.

But here is the problem nobody talks about: the word "service" does not actually mean anything.

ItemService. What does it do? Everything. What is inside? Who knows. You have to open it and start reading. And the more your codebase grows, the more that class becomes a dumping ground, a god class disguised by a reasonable name.

I want to argue that the service as we know it is just one of many distinct types of classes we could be writing. And the moment you start thinking in terms of those types, your code becomes something anyone can navigate on instinct alone.

The Problem With "Service"

When a codebase is healthy, your services are focused. Something like:

/Users
  UserService
  AuthenticationService
  AuthorizationService
  TokenService

/Items
  ItemService
  ItemRepository
  ItemCartService

This looks great. But zoom in on ItemService six months later and you will likely find something like this:

public class ItemService
{
    GetItem(int id)
    GetItems()
    GetItemsByCategory(int categoryId)
    GetItemsByName(string name)
    GetLatestItems()
    UpdateItem(Item item)
    UpdateItems(IEnumerable<Item> items)
    DeleteItem(int id)
    DeleteItems(int[] ids)
    InsertItem(Item item)
    InsertMany(IEnumerable<Item> items)
    UpsertItem(Item item)
    // ...
}

That is not a service. That is a warehouse. It has read logic, write logic, bulk operations, filtering strategies, all crammed under one roof because "it is about items, so it goes in ItemService."

The class is technically focused on one entity. But it is not focused on one responsibility.

Rethinking the Taxonomy

Here is the shift I am proposing: stop thinking of a service as a place where you house logic. Start thinking of it as a datatype.

When you see int, you do not need documentation. You know it is a whole number. You know what operations make sense on it. The name carries the contract. We should hold our classes to the same standard. When you see ItemProvider, you should know just as instinctively what it contains and what it does, without opening the file, without reading a single method signature.

Instead of having one service per entity, you define services by what they do. The name of the class should tell you exactly what is inside before you ever open the file.

The Service

The classic. It still has its place, especially for simpler entities or flows that do not warrant a full split. A proper service handles coordinated logic for an entity, but keeps its surface area small.

public class ItemService
{
    GetItem(int id)
    GetItems()
    InsertItem(Item item)
    DeleteItem(int id)
}

Simple, stable, predictable. If it starts growing, that is your signal to promote some of its responsibilities into more specialized types.

The Provider

A Provider is a read-only class. Every method on it is a query. Nothing writes, nothing mutates. If you need data about an entity, you go to its Provider.

public class ItemProvider
{
    GetOne(int id)
    GetMany()
    GetByCategory(int categoryId)
    GetByName(string name)
    GetLatest(int count)
    GetFeatured()
}

You do not need to read the method bodies. You do not need to wonder whether GetByName has a side effect somewhere. It is a Provider. It gets things. That is the entire contract.

The Mutator

The Mutator is the other half of that split. It owns all write operations. Inserts, updates, deletes, upserts. If data is changing, it goes through the Mutator.

public class ItemMutator
{
    Insert(Item item)
    InsertMany(IEnumerable<Item> items)
    Update(Item item)
    UpdateMany(IEnumerable<Item> items)
    Upsert(Item item)
    UpsertMany(IEnumerable<Item> items)
    Delete(int id)
    DeleteMany(int[] ids)
}

Notice what this does to readability. If you see an ItemMutator being injected somewhere, you immediately know that code is writing data. If you see an ItemProvider, you know it is only reading. Your call sites become self-documenting.

You Already Do This

This is not a new concept. You already apply it to specialized cases without thinking about it.

JobHandler. EmailSender. PaymentProcessor. You already recognized those as distinct enough to deserve their own naming convention. You did not call them JobService or EmailService because the name would have been too vague.

The argument is simple: apply that same instinct to the general stuff too.

A few other types that naturally emerge:

Verifiers handle validation and state checks. Does this entity exist? Is this transition allowed? Is the user eligible?
Transformers map one object to another. DTOs to domain models, API responses to internal types, one version of a POCO to another.

You probably already have logic like this scattered across your services. Pulling it into named types makes it findable and reusable.

Why This Matters

The benefit is not just organization. It is communication.

When a new developer joins and sees ItemProvider, they know where to look for queries. When you are reviewing a pull request and see an ItemMutator injected into a controller, you immediately know that endpoint writes data. You did not open a file. You did not read a method signature. The name told you.

That is the standard we already hold primitive types to. Nobody reads the documentation for bool. Nobody opens the definition of int to understand what operations make sense on it. The name carries the contract, and the contract is never violated.

Your service layer can work the same way. Name the type, keep the class honest to that name, and the codebase stops being something people navigate and starts being something people read.

If you have a DI container, you don't need inheritance

ThatGhost — Sat, 28 Mar 2026 19:03:04 +0000

Part 2 of a series of unconventional programming opinions

This one tends to get a reaction. So let me be clear about what I'm actually saying before you close the tab.

I'm not saying inheritance is always wrong. I'm saying that if your project already uses a dependency injection container — and most modern backend projects do — then you're already holding every tool you need to do what inheritance does. Using both at the same time doesn't give you more power. It gives you two competing mental models pulling the codebase in different directions.

Pick one. And if DI is already in the project, let it do the job.

What inheritance is actually promising you

Inheritance shows up in codebases for two main reasons: code reuse and polymorphic behaviour. A base class that all your repositories extend so they share CRUD logic. A base handler that all your request handlers extend so they share validation. Abstract methods that force subclasses to implement specific behaviour.

These are real problems worth solving. But inheritance isn't the only way to solve them — and in a DI heavy project, it's usually not the cleanest way either.

Reuse: just use a service

The most common argument for inheritance is reuse. You have shared logic — database calls, logging, mapping — and you want it available everywhere without copy pasting.

But that's exactly what services are for. Instead of a BaseRepository<T> that everything inherits from, you write a QueryService (or a DataAccessService, or whatever fits your domain) that exposes the shared logic as methods, and you inject it wherever it's needed.

// Instead of this:
public class ProductRepository : BaseRepository<Product> { }

// Do this:
public class ProductService(IQueryService<Product> query)
{
    public async Task<Product?> GetById(Guid id) => 
        await query.FindAsync(id);
}

The logic lives in one place. It's testable in isolation. Any service that needs it just asks for it. And you haven't introduced a class hierarchy that locks your types into a rigid vertical structure.

Polymorphism: that's what interfaces are for

The second argument is behaviour — specifically, the ability to swap one implementation for another at runtime or test time. A PaymentProcessor that handles Stripe differently than PayPal. A NotificationSender that emails in production and does nothing in tests.

Interfaces handle this cleanly. You define the contract, and each implementation stands on its own. No shared base class, no fragile inheritance chain where changing the parent breaks six children you didn't expect.

public interface IPaymentProcessor
{
    Task<PaymentResult> Charge(decimal amount, string token);
}

public class StripeProcessor(HttpClient http) : IPaymentProcessor { ... }
public class PayPalProcessor(HttpClient http) : IPaymentProcessor { ... }

Your DI container decides which one gets injected. The calling code never knows which implementation it's talking to. That's the polymorphism promise — and you got it without touching abstract or override once.

The hidden cost: base classes need dependencies too

Here's a concrete problem that doesn't show up until a project grows. Base classes aren't isolated — they often need services of their own. And when they do, every single subclass has to carry those dependencies through its constructor, even if it never directly uses them.

Say you have a BaseService that handles logging and auditing. You start with one dependency:

public abstract class BaseService(ILogger logger) { ... }

public class OrderService(ILogger logger) : BaseService(logger) { }
public class InvoiceService(ILogger logger) : BaseService(logger) { }
public class ProductService(ILogger logger) : BaseService(logger) { }
// ... 17 more

Manageable. Then six months later you need to add auditing to the base class. BaseService now needs an IAuditService. So you update the base constructor — and now you have to touch every single subclass to thread that new dependency through.

// You change this:
public abstract class BaseService(ILogger logger, IAuditService audit) { ... }

// And now you're doing this across 20 files:
public class OrderService(ILogger logger, IAuditService audit) 
    : BaseService(logger, audit) { }

public class InvoiceService(ILogger logger, IAuditService audit) 
    : BaseService(logger, audit) { }

public class ProductService(ILogger logger, IAuditService audit) 
    : BaseService(logger, audit) { }

public class ShipmentService(ILogger logger, IAuditService audit) 
    : BaseService(logger, audit) { }

public class CustomerService(ILogger logger, IAuditService audit) 
    : BaseService(logger, audit) { }

// ... 15 more files, same change, every one of them

One dependency added to a base class. Twenty files changed. Zero new behaviour delivered.

With a service based approach, this problem doesn't exist. The auditing logic lives in its own injected service. Only the classes that actually need auditing ask for it. Adding it to more places is opt in, not a cascading update across the whole hierarchy.

Why you should not mix the two

On its own, having to check whether a piece of logic comes from a base class or an injected service is a small task. But you don't do it once. You do it for every class you touch, every time you touch it. That compounds. Over a large enough codebase, that constant context switching quietly eats a significant chunk of your day.

The mental models behind the two approaches are also not equally complex. A dependency graph is straightforward: a class declares what it needs, the container provides it, you can see the full picture from the constructor. Inheritance is a different story. Behaviour is hidden up the chain. Logic you didn't write and didn't ask for shows up in your class because something three levels up decided to put it there. And if that base class itself extends another base class, which extends another — and yes, this happens — you're now archaeology, not programming.

That layered inheritance problem deserves its own callout. Base classes having base classes having base classes is not a theoretical concern. It shows up in real projects, usually gradually, one "it made sense at the time" abstraction at a time. By the time someone new joins the team, understanding what a single service actually does requires tracing a chain that nobody fully holds in their head anymore.

Keeping everything in the dependency graph doesn't eliminate complexity, but it keeps it visible. What a class does is what its constructor says it does. No hidden behaviour, no invisible ancestors, no archaeology required.

The one exception worth naming

There's a legitimate use of inheritance that services and interfaces don't fully replace: extending framework types. ASP.NET controllers extending ControllerBase. EF entities occasionally extending a common audit base. That kind of thing is mostly an API contract imposed by the framework, not a design choice you're making yourself.

That's fine. The principle is about your domain logic — the business layer, the services, the orchestration. Don't build inheritance hierarchies there when your DI container is already set up to do the job more transparently.

The promise of both inheritance and dependency injection is the same thing: write something once, use it many places, swap behaviour without rewriting callers. If you have a DI container, you already have the infrastructure to deliver on that promise. You don't need another mechanism fighting for the same ground.

Keep the hierarchy flat. Let the container wire things together. Your future self will be able to read it faster.

Your /Models folder is lying to you

ThatGhost — Wed, 25 Mar 2026 12:32:25 +0000

We've been trained to separate our POCOs into a neat folder. I'm here to tell you that folder is making your codebase harder to understand, not easier.

Open any .NET solution made by a developer who learned "clean architecture" from a blog post and you'll find it. The Models/ folder. Or maybe it's called DTOs/, or Entities/, or ViewModels/. Inside: 40, 50, sometimes 80 files. A graveyard of classes, half of which you have no idea whether anyone still uses.

This pattern is so common it's treated as a given. And I think it's quietly making our code worse.

The promise vs. the reality

The idea sounds reasonable: keep all your data classes in one place so they're easy to find. But what you actually get is a folder full of context-free classes with zero indication of where they belong or what they're for.

When you open UserSummaryDto.cs, do you know which service uses it? Which endpoint returns it? Whether it's still alive? You don't — you have to go hunting.

The folder doesn't organize things. It just physically separates data from behavior and calls it architecture.

Not every data object is the same

The real problem with the Models/ folder is that it treats all POCOs as if they are the same kind of thing. They are not. Before deciding where a model lives, it helps to think about what role it actually plays.

Some models are purely internal to a single service. They are implementation details, as private as any helper method. Nobody outside that service should ever know they exist.

Some models flow between classes or layers within the same feature. They are part of an internal contract, not quite private but still scoped to a specific area of the codebase.

Some models are genuinely shared across multiple services or features. They represent a concept that belongs to the whole application, and they deserve a clearly visible, shared location.

And some models are not really independent objects at all. They are logical subsections of a bigger model, like a name inside a user or an address inside an order. They only exist because their parent exists.

Throwing all four of these into the same Models/ folder collapses real structural differences into a flat list of files. The folder tells you nothing about scope, ownership, or lifetime. That information just disappears.

Treat internal models like private functions

Think about how you handle private functions. If a method is only used inside one class, you don't move it somewhere else "just in case." You keep it private, right where it belongs. Models should work the same way.

If a POCO is only ever used inside one service, it should be a private nested class inside that service. Not a separate file. Not in a shared folder. Private. Scoped. Invisible to the rest of the codebase, just like a private method would be.

public class UserService
{
    private async Task GetSummaryAsync(int id) { ... }

    // class and its properties only relevant to UserService, never to the outside
    private class UserSummary
    {
        public string DisplayName { get; set; }
        public DateTime LastActive { get; set; }
    }
}

This keeps file count down and makes the intent obvious. Anyone reading that code immediately knows: this model belongs here and nowhere else.

When the model outgrows the service

Once a model needs to be accessible beyond the service itself, it earns its own file. At that point there are two approaches I use depending on how many models a service owns.

If the service has one or two models, a single companion file is enough. It sits right next to the service and the relationship is obvious from the name alone.

/Features
  /Users
    UserService.cs
    UserService.Models.cs   // owns all DTOs for this service
  /Orders
    OrderService.cs
    OrderService.Models.cs

If the service grows and owns several distinct models, you can split them out into individual companion files, one per DTO, all still named after the service that owns them.

/Features
  /Users
    UserService.cs
    UserService.User.cs         // the core user DTO
    UserService.UserSettings.cs // settings owned by UserService
    UserService.UserAuth.cs     // auth data owned by UserService

Either way, there is no Models/ folder at the root. Every file is named after the service that owns it, so you always know where a model comes from and who is responsible for it. The ownership is encoded in the file name itself.

Nested classes for nested data

The same principle applies when one class is conceptually part of another. Take a User that has a name made up of a first and last name. You could create a separate UserName.cs or NameUser.cs file, but that naming is already a hint that something is off. The class only exists because of User. It has no independent identity.

So just nest it:

public class User
{
    public Name FullName { get; set; }

    public class Name
    {
        public string First { get; set; }
        public string Last { get; set; }
    }
}

Now the relationship is explicit in the code itself. You reference it as User.Name, which reads naturally and makes the ownership clear. You haven't added a file, you haven't invented a weird compound class name, and the data is as close to its parent as it can be.

What about shared models?

This is the fair counterargument. Some models genuinely are shared across services and they deserve a shared location. But that should be the exception, not the default. Most models in most codebases are not actually shared. They just live in Models/ because that's where models go.

If a POCO is used by one service, it belongs to that service. Putting it in a central folder doesn't make it more reusable. It just makes it harder to find, harder to delete, and harder to understand at a glance.

The test I use

When I create a new model I ask: is this used in more than one place today? If no, it becomes a private nested class. If it later needs to be shared, I'll promote it then. That's a much better signal than defaulting everything into a shared folder on day one.