Sign up ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free.

I know that when building applications (native or web) such as those in the Apple AppStore or Google Play app store that it's very common to use a Model-View-Controller architecture.

However, is it reasonable to also create applications using the Component-Entity-System architecture common in game engines?

share|improve this question
Check out the Light Table's architecture: – Hakan Deryal Feb 11 '13 at 21:08

2 Answers 2

The Component-Entity-System architecture for game engines works for games because of the nature of game software, and its unique characteristics and quality requirements. For example, entities provide a uniform means of addressing and working with things in the game, which may be drastically different in their purpose and use, but need to be rendered, updated, or serialized/deserialized by the system in a uniform fashion. By incorporating a component model into this architecture, you allow them to keep a simple core structure, while adding more features and functionality as needed, with low code coupling. There are a number of different software systems which could benefit from the characteristics of this design, such as CAD applications, A/V codecs, or other systems which are centered around producing a structured pipeline for diverse content which needs to interact in a complex manner with other types of objects, while still remaining easily modifiable by the development team.

TL;DR - Design patterns only work well when the problem domain is sufficiently suited to the features and drawbacks they impose on the design.

share|improve this answer

If the problem domain is well suited to it, certainly.

My current work involves an app that needs to support a variety of capabilities depending on a bunch of runtime factors. Using component based entities to decouple all of those capabilities and allow extensibility and testability in isolation has been idyllic for us.

edit: My work involves providing connectivity to proprietary hardware (in C#). Depending on what form-factor the hardware is, what firmware is installed on it, what level of service the client has purchased, etc, etc. we need to provide different levels of functionality to the device. Even some features that have the same interface have different implementations depending on what version the device is.

Previous codebases here have had very wide interfaces with many not implemented. Some have had many thin interfaces that were then statically composed in one beasty class. Some simply used string -> string dictionaries to model it. (we have many departments who all think they can do it better)

These all have their deficiencies. Wide interfaces are a pain and a half to mock/test effectively. Adding new features means changing the public interface (and all existing implementations). Many thin interfaces led to very ugly consuming code, but since we ended up passing around a big fat object testing still suffered. Plus the thin interfaces didn't manage their dependencies well. String dictionaries have the usual parsing and existence issues and well as performance, readability and maintainability hellholes.

What we're using now is a very slim entity that has its components discovered and composed based on runtime info. Dependencies are done declaratively and auto-resolved by the core component framework. The components themselves can be tested in isolation since they work directly with their dependencies, and issues with missing dependencies are found early - and in one location rather than first use of the dependency. New (or test) components can be dropped in and no existing code is impacted by it. Consumers ask the entity for an interface to the component, so we're free to screw around with the various implementations (and how the implementations are mapped to runtime data) with relative freedom.

For a situation like this where the composition of the object and its interfaces can include some (highly varied) subset of common components, it works very well.

share|improve this answer
Assuming you're allowed to, can you provide more details on your current work? I'm curious to know what ways the CES has been idyllic for what you are building. – Andrew De Andrade Feb 11 '13 at 20:46
Is there any article, paper or blog about your experience? also, I'd like to have more technical details about it :) – user1778770 Dec 13 '14 at 20:50
@user1778770 - not publicly available, no. What sort of questions did you have? – Telastyn Dec 13 '14 at 20:53
Well, let's start with something simple, does your concept span the whole application stack (e.g. from business to frontend)? or only a single layer of a single use case? – user1778770 Dec 13 '14 at 21:07
@user1778770 - in my implementation, entities/components exist in one layer. Different entities may exist in different layer, but they are often not 1:1 (or else the layers provide no benefit). – Telastyn Dec 13 '14 at 21:20

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.