Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
Boundaries in Large Angular Apps: Feature Folders, Facades and Layers
In a large Angular app you should organize code by feature, split each feature into ui, state, data and domain layers, and allow cross-feature imports only through a public API (index.ts) with rules enforced by lint; the compiler does not know these boundaries. With real output we show three shortcuts passing ng build and being caught by eslint-plugin-boundaries, and cover the facade service and the API client layer.
Component Architecture: Container and Presentational Components, Composition and Contracts
A container component knows about data and side effects, while a presentational component only takes inputs and reports what happened through outputs; the split is not a strict rule but a thinking tool for testability and reuse. We split the Bookstore's product list into three components and show with real output how renaming an input causes NG8002/NG8008 errors, content projection, and how light a presentational test is.
Unidirectional Data Flow in Angular: Signals, input/output and State in Services
Unidirectional data flow in Angular means the state has a single owner, data goes down with input(), change requests go up with output(), and derived values are computed with computed(). With real tests we show how state written by an effect lags behind, how model() bypasses a business rule and why default OnPush misses an array changed in place, then move the state into a service that holds signals.
Flux and Unidirectional Data Flow: Why Didn't Two-Way Binding Scale?
Two-way binding and observable models that update each other produce cascading updates whose result depends on listener order, plus intermediate states that were never valid (glitches); Flux solved this with a one-way flow (action → dispatcher → store → view). We show the glitch with real output on the same order form, cover Redux's three principles and the Elm Architecture, write a 40-line TypeScript store and weigh the cost of immutability and boilerplate.
How Frameworks Map to the Patterns: Is Angular MVC or MVVM? React, Blazor, WPF and ASP.NET Core
Angular is neither classic MVC nor pure MVVM: the component class carries view state and view logic like a ViewModel, the template binds to it, and signals derive the UI from state the way React does. We write and run the same order form with React, Blazor and Razor Pages as well, and show how to read frameworks with three questions (where does state live, how does it sync, can you test without the view) instead of labels.
MVVM and Presentation Model: Data Binding, Commands and the ViewModel
MVVM is Fowler's Presentation Model built on data binding: the ViewModel carries view state and view logic, binding keeps it in sync with the view, and user actions become commands with CanExecute. We write the order form's ViewModel in C# with the CommunityToolkit.Mvvm 8.4 source generators and in Angular 22 with signals, test both without a view, and look at binding's silent failures with real output.
The MVP Pattern: Passive View, Supervising Controller and a Testable Presenter
In MVP the view retreats behind an interface and all screen logic moves into the presenter, so the presenter can be tested in milliseconds with a fake view and no DOM. We build the order form in TypeScript with an OrderFormView interface, a DOM implementation and Vitest tests, and look at the difference between Passive View and Supervising Controller and at how to keep the presenter from bloating.
The MVC Pattern: Original Smalltalk MVC and Web MVC Are Not the Same
In the original Smalltalk-80 MVC, views observe the model and the controller only interprets user input; in Web MVC the view never observes the model, the controller runs once per HTTP request and the view renders once. We build the same order form first in TypeScript with an observable model, then with ASP.NET Core MVC, and compare the two flows along with the fat controller and anemic view model traps.
Why UI Architecture Patterns Exist: Separated Presentation and a Short History from MVC to Signals
UI architecture patterns exist to solve one problem: when screen code and domain logic are tangled, neither can be changed or tested. In this post we move the Bookstore order form from a Smart UI with all logic in event handlers to Separated Presentation, separate view state from domain state, and walk the history from MVC to signals together with the problem each pattern solved.