I have a UI screen which is called "create offer".
Also there is a table in database which is call quote, where this offer will be saved. So ultimately quote <=> offer
In this case what should be the names of my Java classes -> Offer, OfferController, OfferService OR Quote, QuoteContrller, QuoteService etc?
Related
I'm using Laminas framework (formerly ZEND Framework) and would like to know if the DB Adapter automatically strip tags etc. at Insert and Select Statements / Execution ($statement->prepare() / $statement->execute()->current()) to avoid SQL injection?
If not what is the best method to implement it while working with LAMINAS DB Adapter? A Wrapper function to get a clean SQL statement?
Before, I was using a wrapper function that cleaned the input with mysqli_real_escape_string
You'd need to provide some sample code in order to get a more accurate answer to this question, however the topic you're talking of here is parameterisation. If you use laminas-db properly, you won't have to call mysqli_real_escape_string or similar to protect against SQL injection. However, you should still be very wary of any potential cross site scripting (XSS) issues if any data written to your database eventually gets echoed back to the browser. See the section below on that.
How to NOT do it
If you do anything like this, laminas-db won't parameterise your query for you, and you'll be susceptible to SQL injection:
// DO NOT DO THIS
$idToSelect = $_POST['id'];
$myQuery = "select * from myTable where id = $idToSelect";
$statement->prepare($myQuery);
$results = $statement->execute();
How to do it properly
Personally, I make use of the Laminas TableGatewayInterface abstraction, because it generally makes life a lot easier. If you want to operate at the lower level, something like this is a much safer way of doing it; it'll ensure that you don't accidentally add a whole heap of SQL injection vulnerabilities to your code
Named Parameters
$idToSelect = $_POST['id'];
$myQuery = "select * from myTable where id = :id";
$statement->prepare($myQuery);
$results = $statement->execute(['id' => $idToSelect]);
Anonymous Parameters
$idToSelect = $_POST['id'];
$myQuery = "select * from myTable where id = ?";
$statement->prepare($myQuery);
$results = $statement->execute([$idToSelect]);
If you do it in a way similar to this, you won't need any additional wrapper functions or anything, the underlying components will take care of it for you. You can use either the named or anonymous parameter version, however I personally prefer the named parameters, as I find it aids code readability and generally makes for easier debugging.
Sanitising Input/Escaping Output
Be very careful with sanitising input. Not only can it lead to a false sense of security, it can also introduce subtle and very frustrating behaviour that the end user will perceive as a bug.
Take this example: Someone tries to sign up to a site under the name "Bob & Jane Smith", however the input sanitisation routine spots the ampersand character and strips it out. All of a sudden, Bob has gained a middle name they never knew they had.
One of the biggest problems with input sanitisation is context. Some characters can be unsafe in one given context, but entirely benign in another. Furthermore, if you need to support the entire unicode character set (as we generally should be unless we have a very good reason to not), trying to sanitise out control characters in data that will potentially pass through several different systems (html, javascript, html, php, sql, etc) becomes a very hard problem due to the way multibyte characters are handled.
When it comes to MySQL, parameterisation pretty much takes care of all of these issues, so we don't need to worry about the "Little Bobby Tables" scenario.
It's much easier to flip all of this on its head and escape output. In theory, the code that's rendering the output data knows in which context it's destined for, so can therefore escape the output for said context, replacing control characters with safe alternatives.
For example, let's say someone's put the following in their bio on a fictional social networking site:
My name is Bob, I like to write javascript
<script>window.postStatusUpdate("Bob is my hero ♥️");</script>
This would need to be escaped in different ways, depending upon the context in which this data is to be displayed. If it's to be displayed in a browser, the escaper needs to replace the angle brackets with an escaped version. If it's going out as JSON output, the double quotes need to be backslash escaped, etc.
I appreciate this is a rather windy answer to a seemingly simple question, however these things should certainly be considered earlier on in the application design; It can save you heaps of time and frustration further on down the line.
Let's say in my domain I have a Money(amount, Currency(name)) value object (for example: new Money(1000, new Currency('USD'))).
However in my presentation layer (and only there really) I don't want to use USD currency name, but symbol ($) instead.
I don't want to overload my value object with presentation properties (since besides symbol there can be also such things as placement).
How do you guys handle this kind of mappings? Should I create some kind of CurrencyPropertyInMemoryRepository and fetch all info from there? What are my options?
I understand your concern that you want to separate this presentation aspect from your domain data, and if you want to go that way, I think using a repository for mapping the currency name to its symbol might be a good solution (retrieving the correct symbol could then be done in a ValueConverter for example that transforms your model data before they are presented in your UI).
But I personally would not have an issue by storing this additional symbol information also in the currency value object, for two reasons:
The currency symbol is highly related to the currency itself, so whenever the currency name changes, the symbol might also change. Therefore it would make sense to have both information stored in the same place or at least quite close to each other. When using an additional repository, your information is spread at least over two places.
If you have both information within your value object, you could also put additional behavior in your value object (e.g. not every currency has a symbol, in that case you need some logic to decide what to print instead).
I'm looking for some advice on SQL naming conventions. I know this topic has been discussed before but my question is a little more specific and I cannot find an answer elsewhere.
I have some integer variables - generally they would have a name like 'Timeout'. Is there an adopted standard prefixing/suffixing the value so that I know what it contains when I come back to it in 6 months time?
For instance is it 'TimeoutMilliseconds'.
I'm not talking about labelling every variable this way, just those with generic values.
Lookup ISO-11179 for the international database naming standard. for this you can grab this online for free download (though sorry I forget where). There is a lot in it, so here are some some basic summary form it:
Take your field description, remove joining words and write it backwards.
Always end with a class name. There are standard abbreviations like ID for identifier and such.
eg:
Date of Entry:
Entry_Date
Seconds_For_Delivery:
Delivery_Seconds
Name of Widget:
Widget_Name
Location of Widget:
Widget_Location
Size of Widget:
Widget_Size
Also a field should have the same name if it is a primary key or a referenced foreign key. This will pay off in readability for people that come after you, and also most DB tools will assume they are matching keys so you will also save time in using reporting tools and the like (less manual stuffing around putting links in by hand).
In the above examples, the class names are date, seconds, name, location, size. It surprises me that this ISO is not more well known.
I am creating a model in rails (3.2.3) and am defining what columns are to be included (hope thats correct)
for example my first entry is
t.string :Dish_Name
My first question is can I use that syntax i.e. Dish_Name ?
My second question is I want to use dropdowns to select options from the input field, so for exampel i would like to have a "Country of origin" with multiple options, countries of the world.
Would it be better to have a separate DB with all the countries in and then pull in the data from the dropdown? If so could someone point me in the right direction to see how to do this? not necessarily looking for the answer just a good place to start looking
Thanks
Leading uppercase names are reserved for constants. Typical column names are lowercase with underscores (e.g. dish_name or country_of_origin). These are Ruby conventions, and Rails follows along. Naming conventions matter in Ruby, unlike a language like C#, where you call anything just about anything with any casing you want.
Be sure to check out guides.rubyonrails.org for a lot more information.
This has been bothering me for a while, and I can't arrive at a solution that feels right...
Given an OO language in which the usual naming convention for object properties is camelCased, and an example object like this:
{
id: 667,
firstName: "Vladimir",
lastName: "Horowitz",
canPlayPiano: true
}
How should I model this structure in a PostgreSQL table?
There are three main options:
unquoted camelCase column names
quoted camelCase column names
unquoted (lowercase) names with underscores
They each have their drawbacks:
Unquoted identifiers automatically fold to lowercase. This means that you can create a table with a canPlayPiano column, but the mixed case never reaches the database. When you inspect the table, the column will always show up as canplaypiano - in psql, pgadmin, explain results, error messages, everything.
Quoted identifiers keep their case, but once you create them like that, you will always have to quote them. IOW, if you create a table with a "canPlayPiano" column, a SELECT canPlayPiano ... will fail. This adds a lot of unnecessary noise to all SQL statements.
Lowercase names with underscores are unambiguous, but they don't map well to the names that the application language is using. You will have to remember to use different names for storage (can_play_piano) and for code (canPlayPiano). It also prevents certain types of code automation, where properties and DB columns need to be named the same.
So I'm caught between a rock and a hard place (and a large stone; there are three options). Whatever I do, some part is going to feel awkward. For the last 10 years or so, I've been using option 3, but I keep hoping there would be a better solution.
I'm grateful for any advice you might have.
PS: I do realize where the case folding and the need for quotes is coming from - the SQL standard, or rather PostgreSQL's adaptation of the standard. I know how it works; I'm more interested in advice about best practices than explanations about how PG handles identifiers.
If your columns in the PostgreSQL are with underscores, you can put aliases but with doule-quotes.
Example :
SELECT my_column as "myColumn" from table;
Given that PostgreSQL uses case-insensitive identifiers with underscores, should you change all your identifiers in your application to do the same? Clearly not. So why do you think the reverse is a reasonable choice?
The convention in PostgreSQL has come about through a mix of standards compliance and long-term experience of its users. Stick with it.
If translating between column-names and identifiers gets tedious, have the computer do it - they're good at things like that. I'm guessing almost all of the 9-million database abstraction libraries out there can do that. If you have a dynamic language it'll take you all of two lines of code to swap column-names to identifiers in CamelCase.
I know this is late however for something that would be simple to translate on the fly, you could write a small help function that would live in your code as such:
function FormatObjForDb(srcObj){
const newObj = {};
Object.keys(srcObj).forEach(key => newObj[key.toLowerCase()] = srcObj[key]);
return newObj;
}
export const formatObjForDb = FormatObjForDb;