OOD vs MVC; Live Objects vs Everything in Database

Question

How to make memory-efficient code, but still have all the possible code nicely encapsulated ?

I have a feeling that the OO (object oriented) approach is more intuitive and the code is nicely organized and encapsulated, but it can use a lot of memory, because there are usually many live object instances in the memory.

In contrast, the MVC (controller, model (database)) approach code is much less encapsulated but uses much less memory, because the objects in memory are only when some client asks for them, and then they are disposed.

---

I need to make an internal health monitoring system, to periodically ping ip cameras. There will be about 10,000 items (cameras) to monitor, with a boolean state - Good / Bad.

If I go the OO way - I will hold a class for each of the item, with its ping result, timer, events to notify some other items. So I will end up with 10,000 instances in memory all the time. There is not much, but what if there were 100,000,000 items. I prefer this way, because it is intuitive and I have a perfect (encapsulated) place for any code I may need to run in the concrete item class (timers, events, handlers, subscriptions).

If I go the MVC way - I will hold all the data in database, so the memory usage will be minimum. But I will have to improvise a way to trigger code execution, like periodic timers, events, handlers, subscriptions. And that code - where will it be written? Will it be nicely encapsulated? Also, what code will call those triggers? Will it also be encapsulated? For example, I can make a timers engine, and hold a dictionary of timers for each of the 10000, but then the code will not be encapsulated.

Answer 1

OO

Can be done regardless.

Even MVC is an OO design pattern, first introduced by SmallTalk a pure OO language.

Unless we are talking about a language such as JavaScript, most languages support a tightly packed data structure. So doing something OO isn't going to impact on memory efficiency very much.

A few caveats emerge when you introduce flexibility like subclassing, mixins, and property bags.

MVC

I don't think you have a tight grasp on what MVC actually is.

I think you are instead talking about Active Record sets, or similar technology where the database tables are themselves exposed as tables to your own functions.

Now it is possible to use an Active Record as the Object Model in an MVC implementation. In which case it is unfair to state that the code is less encapsulated.

• There was an active choice to work at the level of sets of things instead of with a thing.
• There was an active choice to use a data-agnostic and thus business logic anaemic representation.
• There was a choice to house the business logic externally. (Otherwise the active records themselves would have been wrapped by an object).

How much memory?

• 1 byte for a Boolean
• 6 bytes for an IPv4 + Port (18 bytes for an IPv6 + Port)
• 16 bytes for a GUID
• 8 bytes for ticks at last check
• 8 bytes for polling delay (if each camera can be polled on a different cadence)

That gives you:

• 39 Bytes (48 Bytes Padded to 16Byte alignment) for an IPv4
• 51 Bytes (64 Bytes Padded to 16Byte alignment) for an IPv6

1Gb of memory (1024 * 1024 * 1024 bytes)

• 22,369,621 aligned IPv4 camera instances (27,531,841 unaligned instances)
• 16,777,216 aligned IPv6 camera instances (21,053,761 unaligned instances)

With a few tricks, it is possible to squeeze this even further down.

Dilemma

But no matter what you do this data will exist somewhere, be it stored in the database, or in the program itself.

Note that if a program asks for more memory than can be stored in RAM, it will be paged to the disk, exactly like it would happen in a database.

A Modern computer with access to even 2GB of ram, and an SSD is more than capable of marshalling the 6GB of Memory space required for your 100,000,000 instances, because the addressable space in most 64bit applications is currently around 2^40. Well in excess of the range before you need to worry about manually swapping data out of the process to free space for further work.

If that appears to be too slow, the cheapest way to actually improve performance would be to upgrade the servers ram. 16GB is not that expensive these days, and even 64GB is reasonably priced.

If for some reason your client, who can presumably afford 100 million cameras, cannot afford either several servers each working on a subset of the problem, or enough ram to house it all in one machine, then there is not much you can do.

Database

What purpose does this database serve for you?

• Is it just a serialisation format, to just save all the data in your program to, and then load it up again?

• Is it an integral part of the algorithms and processes that your are implementing providing data crunching, memory management, and multiple concurrent access?

Answer 2

There is a fundamental misunderstanding when you oppose OOD and MVC.

• MVC emerged in the area OOP and more precisely in a Smalltalk environment.
• The separation of responsibilities between objects in the MVC pattern is in fact meant to improve the encapsulation and the clean collaboration between objects in a complex system, not to get rid of them.
• Well designed objects do not necessarily mean memory intensive.

There is another misconception, associating MVC with a database orientd M that would short-circuit objects in memory. MVC is agnostic how the M interacts with the database. And there are many ways to design the M, for example:

• Transaction Script and Table Module implement the model using a direct bridge to the database.
• Domain Models implement the model using in-memory objects that use some repositories and other intermediary objects to interact with the database.
• Active records are a variant of domain models where each memory object saves itself in the database

But there are plenty of other variants. And it's not because you'll keep a couple of domain objects in memory that you will exhaust your system (it's never the full database that is loaded, only what's needed).

If you're looking for a nice design of your M in the MVC, without loosing any of the advantages of OOD, and understanding the pros and cons of the different alternatives, I can recommend you Martin Folwers great book "Patterns of Enterprise Application Architecture". There are several chapters devoted to this subject.

Answer 3

Your assumption that you have to have an object for each ip camera if you do OOP does not hold. Also, you seem to be assuming that ip camera objects needs to hold the data associated with them at all times or that every ip camera object has to be present at all times, this is also not true.

I know this is unfortunately what OO looks like in many projects, but neither assumption is actually needed for OO. In OO you model what you need exactly. If you just want to present the current values why not do:

public interface IpCameras {
   UIComponent displayState();
}

There is no reason in OO whatsoever to have anything more than that, if this is your use-case. All the "patterns", "MVC", stuff like that doesn't really matter. Do proper modelling and most if not all optimization problems will have a proper place to go to.

Update: with more requirements. Pinging and timing: I would assume scheduling code is already there on the platform, so I would perhaps do this:

public interface IpCameras {
   UIComponent displayState();

   void pingAll();
}

With pingAll() called to ping through all cameras. This could be internal too, the IpCameras could do this without exposing this method, both are fine.

To notify things, perhaps this method could be extended with a parameter:

void pingAll(PingClient client);

public interface PingClient {
   void onPinged(...ip camera...);

   void onFailed(...ip camera...);
}

You then can have multiple implementations of PingClient, separating the different things you want to do with this information. Some implementations might be: PingClients (for more then one client), RealTimeClients (for online apps), NotificationsClients (for email clients or whatever), ThreeFailsClient (to fail the delegate only when 3 consecutive fails were registered), etc.

Again, you can do all this without instantiating an object for each camera and without keeping any superfluous data in memory while completely preserving encapsulation.