Blog
Mert Özen's blog posts on software development, backend, frontend, and DevOps.
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.
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.
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.
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.
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.
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.