Timeline for Why does "a consistent, understandable interface" differentiates database from global states?
Current License: CC BY-SA 4.0
10 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 10, 2024 at 19:01 | comment | added | Steve | @GregBurghardt, and just to give an clear example, if I yank a network cable which connects the client to a database server, I'm changing the profile of the interface which the software uses, without ever touching or altering the software code itself. The fact that this cable yanking can happen under reasonably common circumstances - whereas main memory is designed never be yanked from the computer - is a part of the implied profile of the interface which isn't recorded in source code at all but which the competent application designer must account for in the design. (3/2) | |
| Apr 10, 2024 at 18:55 | comment | added | Steve | There are many characteristics of an interface, such as it's performance profile, it's relative chance of proceeding to completion, or the durability of data it stores between calls, which are not defined in source code as part of the explicit definition of the interface (in any language I know), or even fixed by code at all (rather than the condition and capabilities of the hardware), but are extremely relevant to the overall design and the manner of usage of a particular interface. (2/2) | |
| Apr 10, 2024 at 18:54 | comment | added | Steve | @GregBurghardt, I know the pattern you mean and I agree, but still the design of the application as a whole would reflect that the designer had the knowledge and intention that database calls would occur rather than assignments to globals. You can read and write from globals willy-nilly, whereas reading and writing to a database would be far more controlled. The data shape of the "interface" for the DAO might not reflect this, but by god the application's design as a whole (including the workings which sit both sides of the interface) would reflect the additional constraints. (1/2) | |
| Apr 10, 2024 at 18:24 | comment | added | Greg Burghardt | @Steve: by "knowledge" I mean the class names or API required to use a particular type of storage. You don't want your database connection objects directly referenced everywhere in your application. Typically, these types of objects would be used in some sort of "data access" object. The rest of the system uses the data access object rather than the database drivers directly. That is the abstraction. | |
| Apr 10, 2024 at 18:20 | comment | added | Steve | @GregBurghardt, whose "knowledge" are we talking about? I've never designed an application where I didn't know (or care to know) whether I was interacting with main memory, or interacting over the network with the durable storage of a client-server database engine. If nothing else, the reliability of an access to main memory is a world apart from the reliability of a database call. I see failed database calls daily - I don't recall a known case of a failed main memory access in my entire lifetime. It doesn't seem sensible to me to suggest "abstracting" these details. | |
| Apr 9, 2024 at 16:24 | comment | added | Ewan | Yeah I agree, hope people read till the end | |
| Apr 9, 2024 at 15:53 | comment | added | Greg Burghardt | @Ewan, I think the intent of that first sentence concerns knowledge of the database or global variables. Only a certain part of the application should know about the database, but the other parts should be dealing with data access objects or repositories. The OP mentions using a bunch of Database specific code all over the application. I understood "don't use database in your application code" to mean "use an abstraction instead." | |
| Apr 9, 2024 at 15:17 | comment | added | Ewan | bold first sentence! | |
| Apr 9, 2024 at 12:28 | comment | added | Greg Burghardt | The important difference is that you should be creating abstractions over top of any database specific code so the rest of your application doesn't need to deal with it. Those "other abstractions" are precisely the "consistent, understandable interface" you are asking about, @wcminipgasker2023. | |
| Apr 9, 2024 at 8:12 | history | answered | gnasher729 | CC BY-SA 4.0 |