As we know, the schema specified for this assignment allows you to pad fields for records in the data file with the empty string in order to fill them up to the maximum length allowed by the schema.
Using this approach means that you never have to deal with records being shorter than the max length specified in the schema. It also has the benefit of ensuring that all records are exactly the same length - this simplifies reading\writing to the file and allows you to quickly validate the file based on the overall length of the file.
However, I am wondering if this approach could be looked upon negatively by the markers of this assignment. Because this approach means that you can never have null for a field in the database (data file). Also you cannot differentiate between null and the empty string.
In database terms it is equivalent to saying that all columns on the table have a non-null constraint. I see nothing wrong with this in theory. But the schema we have doesn't disallow nulls, yet padding fields means you are disallowing nulls. This is a limitation then? So I am wondering if it would be looked upon negatively?
Question About My Approach
At my Data Layer nulls are not allowed. So when reading records you will receive a list of arrays where each record is an array. You are guaranteed that all elements of an array are valid Strings. If an element of an array is the empty String, then this either means that it was set as the empty string or was not set to any value. When writing records back to my Data Layer you send in a list of arrays. Elements of the array must be valid Strings i.e. null values are not allowed. This is to keep the read and write consistent.
When I am at my Business Layer sending data to the client I convert an array record into a transfer object. If an empty string exists in the array, then I set the corresponding field in the transfer object to be null. The reason I do this is that it is a commonly used approach that when a getter method returns null this implies that the value is not set.
When the client is sending data to my Business Layer it must use the transfer object. Now the client can set a field in the transfer object to be valid String or null. This is because my setter methods do not prevent the client from setting nulls. My thinking here is based on two reasons:
1) It is OK to let the client send whatever data it wants to the Business Layer - then at the Business Layer this data will be validated and either accepted or rejected.
2) Consistency. The Business Layer sends the transfer object to the client and it may contain nulls. So for the sake of consistency, the client should be allowed send transfer objects to the Business Layer where a field is set to null.
How does my approach seem to you guys? Does it seem intuitive or confusing? Feedback welcome
I think you should do a bit less thinking and a bit more coding
They give you a file with all fields having same length, space padded. So how can it be looked upon negatively if you can't differentiate between nulls and empty strings. It's the file format the company uses (and to which other programs are developed). So adopting a specific approach where you can differentiate between nulls and empty strings may break other applications.
About your approach: I followed a similar approach, so no remarks about that one