Metadata, Naming & Class Demands

A mapper has to know, for every mapped class, which table stands behind it, which column stands behind each property, which member carries the key, and how links to other classes are stored. That body of knowledge is **mapping metadata**. Nothing in the mechanism forces it into one particular place, and data-access layers genuinely differ here: some read it from the class, some from a document beside the code, some from calls made while the application boots, and some derive nearly all of it and read almost nothing. ## The four placements 1. **On the class.** The rules are written as declarations sitting next to the member each one describes. The mapping is discovered by reading the class, so it travels with the code, and a rename carried out by a refactoring tool moves the declaration with the member. 2. **In an external configuration document.** A file beside the code names the class, its table, and each property-to-column pairing. The class itself contains no storage detail at all. 3. **Through a configuration API called at startup.** The application builds the mapping in code as it boots: for this class, this table; for this property, this column. Because it is ordinary code, it can branch, loop over a set of classes, or be assembled differently in a test. 4. **By convention only.** Nothing is declared. A **naming strategy** derives the table name from the class name and each column name from the property name, and simple rules decide which members are mapped at all. ## What each placement buys and costs | Placement | Strength | Weakness | |---|---|---| | On the class | Co-located with the members; survives a rename; one place to read | Storage concerns inside the domain type; one mapping per class; changing it is a code change | | External document | Class stays clean; a different document per environment; editable without touching the class | A rename leaves a dangling name nothing checks; the mapping is far from the code it describes | | Startup API | Rename-safe, conditional, testable; works for classes you cannot edit | The mapping is spread through boot code; it is only visible by running or reading that code | | Convention only | Nothing to write or keep in sync; uniform by construction | The rule is invisible in the source; a reader must know the strategy to predict any identifier | ## Conventions are rules, not their absence The common misreading of convention-driven mapping is that "no declaration" means "no decision". It means the opposite: a decision was made once, globally, and applied to everything. The identifiers still exist, the nullability still has a value, the set of mapped members is still fixed. The only difference is that none of it is written where the reader is looking, so predicting the schema requires knowing the strategy. That is a real trade. Conventions remove a large amount of repetitive declaration and make the schema uniform. They also mean that renaming a property changes a column name, and that a member added for a purely computed purpose may be mapped unless it is marked otherwise. ## Combining them Real setups rarely pick one placement and stop: - **Convention first, override the exceptions.** The strategy handles the bulk; a handful of legacy tables and reserved-word columns get an explicit name. - **Precedence has to be defined.** When both a convention and an explicit declaration apply, the explicit one wins; when a document and an on-class declaration disagree, the layer's documented order decides, and relying on that order by accident is a defect waiting to happen. - **Per-environment differences** are the classic reason to move a rule out of the class: a schema name that differs between environments belongs in something selectable at deploy time, not compiled into the type. - **Classes you do not own** — types from a shared library — can only be mapped from outside, which is what a startup API or a document is for. ## What an interviewer is listening for A candidate who can only describe declarations on the class has used one layer and generalised from it. A strong answer names more than one placement, says what each one costs, and recognises that convention-driven mapping is a default that has to be learned rather than an absence of rules. The follow-up is almost always about overrides: how you keep one legacy name from forcing you to abandon the convention everywhere else.