How to handle multiple models that relate to a single model

Question

First of, sorry for the vague title.

In our website framework, we have modal classes to represent our database tables, that hold a rows data. I'm currently working on a stat style page, and I'm wondering how other programmers handle linking lots of models together.

For example, on the page, I'm listing all Customers, with there respective Addresses (multiple per Customer. Home, billing, work etc...), and every Order which links to the Customer and Address.

The only options I can think of, are:

Ditch the models, bring back a raw array from a join query, that has all the data needed.
Bring back all the different models, and sort them into an array, e.g $customers[0]['customer'], $customers[0]['addresses'] etc...
Create some sort of strange hybrid model that either holds all the data, or holds models.

None of these to me seems particularly ideal, but I don't know of any other ways to do this.

I'm currently using number 2, but I'm curious if there is a different way I could approach this.

Are there any other ways people manage this kind of scenario?

Does your application support order shipping to an address other than one listed under the customer's account? — ravibhagw
– ravibhagw, Commented Aug 28, 2015 at 17:38

Cormac Mulhall · Accepted Answer · 2015-08-28 16:17:37Z

So by the sounds of it you have an anemic domain model

http://www.martinfowler.com/bliki/AnemicDomainModel.html

This is a problem because you have objects that aren't actually doing anything other than holding data, but you have all the overhead of classes and objects without any behaviour.

If you can't figure out what your objects are doing other than just storing data, then they aren't objects. Objects are units of behaviour, not data. Objects that don't do anything other than hold data for something else are a design smell. It means your behaviour is some where else, but those objects/units of behaviour don't have access to the data they need to carry out their behaviour.

So I would go with option 1 since you seem to just need data structures. I would also look at the over all design again and see where your behaviour has gone missing to.

»So by the sounds of it you have an anemic domain model« In this case, I would not speak of an anemic domain model, since it is really about serializing the data and not about objects with business logic attached. Perhaps you could speak of "view models". On the server side, these "models" may be not so anemic as it sounds here. — Thomas Junk
– Thomas Junk, Commented Aug 28, 2015 at 17:06

Thomas Junk · Accepted Answer · 2015-08-28 17:03:34Z

You are simply lacking something called ORM - either via a Framework or (only in some use cases recommended) handcrafted. Via ORM you define the Entity Relationships via code (e.g. 1 Order <-> n OrderPositions). And if you are using a framework the magic begins: you are able to resolve in one coded query all/most relationships which are needed - Little sidenote: sometimes this is not wanted and would later on in the product lifecycle cause problems.

After you retrieved your data from the database, the important part of the ORM kicks in: assembling the objects from the data retrieved and not only that; it creates the whole object graph (i.e. every related object is put in place - so to say).

After that your webframework (typically) serializes the data to JSON

Your frontend gets something like this:

{ "posNr": "1", "description": "My Life with a nashorn", "price": "1990", "ordernumber": "1234", "customer": { "firstName": "Alice", "customernumber": "123456789", "address": { "street": "bakerstreet 221b", "city": "london" }, "links": [{ "rel": "customer", "href": "http://localhost:8080/customers/1" }] }, "links": [{ "rel": "self", "href": "http://localhost:8080/orders/1234/1" }] }

That said: If you need a collection of customers with their respective orders etc. you simply request a Collection from your application which would result an Array of the above structure.

In principle, this resembles your option 2. But you are doing it unnecessarily manually.

Stack Exchange Network

How to handle multiple models that relate to a single model

2 Answers 2

Hot Network Questions

How to handle multiple models that relate to a single model

2 Answers 2

Related

Hot Network Questions