Tag Info

New answers tagged

0

One thing you should never keep in the database are the details needed to access the database. You've a bit of a catch-22 if you need to access the database to retrieve the connect strings, username, and password for that same database after all. Hardcode it? hmm, might work if you're using some sort of database that installs and ships with the application. ...


0

What you are also missing is "program control" type information say max buffer size, number of items aloud in an order, max page size for a screen is always better either hard coded in the program or in a configuration file. If you keep this sort of data in a database there is always the possibility of someone changing it on the fly and completely changing ...


1

The distinction is indeed a somewhat gray area, but my approach to this kinds of issues is: does the data change in production"? Anything that changes after deployment in a production environment should go in the database, even for things that may rarely change. So the question you should be asking is not "how often will it change?", but "can it change?". ...


2

If there's even the slightest chance you will ever get a phone call resulting in you having to rebuild an application because something hard-coded has changed, then don't hard-code it. At the very least keep it in a config file or db table. You don't have to provide any UI to maintain it necessarily, but dialling in and changing a config file or running an ...


3

It is neither the frequency of changes nor the amount of data that decides where to store data. If the data is required to run the program, it is part of the program code, so store it as a constant. All other data goes in the database. Of course, config files, images, sounds, etc are usually better stored on the filesystem.


8

I think the premise of the question is not quite right. The dividing factor is not the quantity of records that need to change, but the frequency of changes as well as who changes them. Frequency When data is volatile, in the sense that it changes often and outside of a release cycle of the software, it needs to be able to be configured outside of ...


24

I don't think these two statements really represent a consensus about when to hard code data: If it is a single variable or a simple structure, or an array of a few values, put data right in the code If it has hundreds+ of rows of data of the same type, use a database Simple counter-example (I am sure there are better ones): programming language ...


14

I'd go with the third option: a config file! For applications that I work on (in Java, so all my examples are use Java+Spring ), such values are usually stored in config files and injected (via Spring) into the code that needs them when the application starts up. In a properties file: motorFramesString=412T, 413T, ... In the spring config: ...


4

Short answer: yes. While we'd all like to tinker around and build neat things there will always be the need of shipping the darn thing before going out of business. Long answer: it depends. Requirements and the skill level of the team can influence the decision of choosing one over the other, having both or having none. With a tight deadline comes focus ...


1

One case comes to mind where the constructor/destructor does all the work: Locks. You normally never interact with a lock during it's lifetime. C#'s using architecture is good for handling such cases without explicitly referring to the destructor. Not all locks are implemented this way, though. I have also written what amounted to a constructor-only bit ...


1

There are patterns common in languages where functions and classes are much more the same thing, like Python, where one uses an object basically to be function with too many side-effects or with multiple named objects returned. In this case, the bulk, if not all of the work may be done in the constructor, as the object itself is just a wrapper around a ...


2

Depending on your setup, email can occasionally take an unreasonable quantity of time to respond, and it can fail ambiguously and need retries. So I would suggest that this is one of the times when a service is in order. Either in the form of a service of your own, or of an SMTP server you have control over. The local SMTP server presents a better-known ...


7

Basically, you have two issues here: E-mails are dispatched from presentation layer, The API is tied up to physical e-mail implementation. The first issue is solved by the first step of moving the code where it belongs: in business layer. You shouldn't save companies from presentation layer, and you shouldn't send e-mails from there: move all this code ...



Top 50 recent answers are included