This is a software design question. Not sure how to ask, so I'll illustrate with a scenario. I'll update the title to help reference for others if there is a better way to ask.



BizLogic is the Business layer in a typical MVVM. It handles typical CRUD operations on a List. A requirement is that Data comes with an Age counter. The BizLogic is the only class that should access Data.Age, as it uses the Age field for pruning the List. However, the ViewModel needs access to the Data object to pass over to the presentation layer.

My question is, what is the best way to hide the Age field so that ViewModel doesn't inadvertently mess up BizLogic?

  • Instead of having an Age field on Data, can you have BizLogic contain a dictionary which gives the age for each Data object? Sep 13, 2016 at 2:40

2 Answers 2


What would the UI be doing with Data that should not be in BizLogic?

custom Collection

[BizLogic] uses the Age field for pruning the List.

A custom DataCollection is in order. Single responsibility applies even if BizLogic is the only client. I assume your language, and collection classes thereof allows a code block, LINQ, etc. injection to provided "Find" methods.

Given a collection with appropriate functionality you may not need BizLogic for the presentation layer to do it's thing.

Two Data classes

I hope there is no such thing as a "parallel structure". You don't want to force clients to write code for this. Controlling Age exposure should be designed in either through a composite class or through inheritance. Certainly the aforementioned custom collection and possibly BizLogic can emit proper Age-less objects from it's internal Data.

First blush on reading @Caleb answer, I thought "blanking out" Age was good but then, no. This makes invalid data objects. full stop.

  • A custom collection sounds like it might work. Maybe a List<Tupple<Data, Int>>... I'll have to play around with. Thanks Sep 15, 2016 at 3:16

what is the best way to hide the Age field so that ViewModel doesn't inadvertently mess up BizLogic?

The best way probably depends on which language you're working in and how adversarial you want the relationship between the data model and view model to be. Here are two options:

  1. Hide the interface to the age information. One way to implement this would be to have a public interface to the Data object that's all that's known to the world outside the data model, and a more detailed interface that's known only within the data model. One way you could implement this is via inheritance. For example, you could have a PublicData class that provides the operations that any client of the class can use, and a BizLogicData subclass of PublicData that provides the additional functionality to keep track of data age and any other stuff you don't want the whole world to know about.

  2. Keep the age information separate from the rest of the data. If BizLogic is responsible for inserting and deleting items in the Data object, it should be possible to maintain a separate, parallel structure that keeps track of the age information for each item. Or, you could keep the age info with the rest of the data, but expunge it from any copies of Data that you provide to outside clients.

Trying to keep parallel structures in sync is always problematic, so I'd prefer for the first option when possible.

  • I thought of inheritance too, but I quickly found my code constantly converting data. Even though its small, its a bit of a performance hit I think could be avoided. The second suggestion isn't bad, but I'm worried that approach will cause a maintainability nightmare if these things get out of sync. Any other dev wouldn't see the relationship between two independent data structures. Sep 15, 2016 at 3:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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