Model Architecture: What Is the Best Way to Handle Listing Complex Entities?

I have an MVC architecture question that I’d love to get your input on. I’m developing an app using Coldbox and I’m struggling a bit with how I should build out my entities and services.

For this example, let’s say I was creating a service to work with Campgrounds (you know, those places with tents, lots of dirt, and mosquitoes). Campground entities, in this project, are rather complex objects because they have a lot of properties, nested value objects, and a few behaviors.

My CampgroundService is going to have some pretty standard methods like getById() and list().

The getById() method is pretty straightforward and will primarily be used when displaying detailed information on a single Campground.

Things get tricky with the list() method. The list() method accepts a filter object argument that contains criteria to filter by. For example, there may be times when I need to grab a list of campgrounds for an entire US state or a list of campgrounds based on a bounding box of geospatial coordinates (i.e. latitude and longitude).

The views that respond to the list() methods generally only need a small subset of the data contained in the full Campground model. For example, most of the time when listing I only need the name, state, altitude, latitude, and longitude. It feels like overkill to have to build out the full Campground model with all the nested objects every time I want to get a list of campgrounds that matches the search criteria.

My goal is to figure out what is the recommended approach for handling this type of setup in an app. Here are some possible solutions I have been considering:

1. Caching.
Caching would handle the speed problem on subsequent requests for data, however, storing potentially large arrays of entities in memory seems like a bit of a waste. Additionally, there may be times where I cannot really cache the data because one of the views in the app uses the Google Maps API and sorts campgrounds by the geographic data type. I have MSSQL (via my DAO) doing the heavy lifting here for geo spacial sorting since it does it very quickly and the reference point for sorting could change rapidly (when the user moves the map around).

2. Create a “Summary” Campground entity
I could create a new entity object called CampgroundSummary which would only hold the most basic fields for Campgroud listing. I expect this model would be much more lightweight and faster to assemble than the primary Campground model. However the downside is that I feel like I’m violating the DRY (don’t repeat yourself) principal by creating similar (albeit abbreviated) entity objects.

3. Forget Objects and Return an Array of Structs Instead
I could forget about returning an array of objects altogether when listing data, and instead, just return an array of structs or even a query object. This feels very “old-school” to me, but the performance advantage could make it worthwhile - especially for the Google Maps API view functionality. The downside of this approach is that I lose the advantages of using objects which enforce data integrity and could include behaviors down the road if I need them.

4. A Combination of 2 and 3
Simplifying the model into a CampgroundSummary might be ideal in cases where I need to show a list of campgrounds by sate, but only need a small subset of properties. I could even cache that data too to make it load lightning fast. However, for the Google Maps stuff where performance is the top priority, I could create a separate method in my CampgroundService which would return a simple array of structs.

Anyway, I know this is a lot to digest, but I’d love to hear your thoughts and opinions. Also, if you have links to any articles that describe this topic, I’d love to read more about it. I searched Google extensively and couldn’t find anything - perhaps I am using the incorrect vocabulary for this scenario.

Thank you!