5 ms·

Here are two concrete problems that these general design articles never answer: 1. How to deal with global dependencies like logging, internationalization, app

Here are two concrete problems that these general design articles never answer: 1. How to deal with global dependencies like logging, internationalization, application "constants" (not always constants in the programming language), preferences, ...? If you inject these as dependencies into every module or package, then you end up with a convoluted mess of initialization parameters and dependencies. If you make them globally accessible, re-usability is lost almost totally. In both cases, the code depends on the preference system and the particular values of preferences. (In a real-world application almost every "constant" has to be parametrized as a preference.) 2. Closely related to this, how do you deal with miscellaneous data that any real-world application needs, but that pollute and "impurify" your objects and classes. Typical examples of this second category are binary data from rich text and other potentially volatile and framework-dependent data---often, but not necessarily only GUI-related. If your application is database-driven, you have to store this data, which usually means you also have to store it in a class or struct in your programming language. For example, you might not just need to store an employee name, you might also need to store employee name richtext data, employee name display flags and filter category information, and so on. Trying to strictly separate model data from view-related data basically just gets you twice as many classes and tables for a little bit of gain in "purity." That is true even if you follow a strict MVC pattern (which I usually do), and in the end you store all of the data in the same database file anyway. I'm currently using Go, but the same problems also came up in Racket for in the past. I've never read any software design article that provided concrete solutions to these problems. I wish those articles would stop discussing toy examples about cars and employees and instead explain how real-world problems are solved.

mdpopescu 7y ago
1. Decorators. See https://blog.ploeh.dk/2010/04/07/DependencyInjectionisLooseCoupling/ https://blog.ploeh.dk/2010/04/07/DependencyInjectionisLooseC... 2. Yes, you need a lot of model types (groups, layers). You need the view models, the database models, the business logic models, and possibly others. Sure, that's annoying at first because they're pretty much identical. That's fine though, because in that case you can just use AutoMapper or something similar. I have never seen a project where the various models didn't change independently in a short timeframe (weeks, months at the most).

mdpopescu 7y ago

1. Decorators. See https://blog.ploeh.dk/2010/04/07/DependencyInjectionisLooseCoupling/ https://blog.ploeh.dk/2010/04/07/DependencyInjectionisLooseC... 2. Yes, you need a lot of model types (groups, layers). You need the view models, the database models, the business logic models, and possibly others. Sure, that's annoying at first because they're pretty much identical. That's fine though, because in that case you can just use AutoMapper or something similar. I have never seen a project where the various models didn't change independently in a short timeframe (weeks, months at the most).