I have a simple code-first project. In one of the POCO objects, I have the following property:
```
[Required]
[StringLength(3, MinimumLength = 3)]
public string TestString { get; set; }
```
I expected the Add-Migration command to create the following output:
```
TestString = c.String(nullable: false, maxLength: 3, fixedLength: true),
```
However, I get the following output:
```
TestString = c.String(nullable: false, maxLength: 3),
```
I've check the StringLengthAttribute for any property that would allow me to specify a fix length but there isn't any. Therefore, (IMHO) FixedLength should be set using code something like this:
```
FixedLength = MaximumLength == MinimumLength;
```
Comments: Please reconsider, because I think you have missed the point I was trying to make.
First, I agree that the database should NOT be in the business of validating the minimum length of any string.
Second, as you know, SQL provides many types, including VARIABLE and FIXED length strings. And we all know, a fixed length string has better performance than a variable length string. (see: [here](https://social.msdn.microsoft.com/forums/sqlserver/en-US/47bfe0ed-daf0-4cd3-bfbd-ca0c17044853/which-is-best-in-performance-char-or-varchar), [here](https://ask.sqlservercentral.com/questions/20960/char-vs-varchar-index-performance.html) or [here](http://www.sql-server-performance.com/2007/datatypes/)).
From a pure EF code-first approach, developers SHOULD be able to define their database types from their data model; otherwise, Entity Framework "provides little-to-no value".
Let say that a given domain calls for a property to be of fixed length. For example: the Foreign Exchange markets uses a fixed length symbol of 6 characters, like: USDJPY or EURUSD. From a C# language standpoint, this requirement could be implemented as an array of 6 characters ```char[6]``` or a string (which is normally easier to work with). From a database storage standpoint, a FIXED length string (```CHAR(6)```) would be more efficient than a ```VARCHAR(6)```.
Third, your statement assumes that no validation has occurred. Where in fact, any "real-world" project would require validation. Which is normally performed in one or more places; such as the GUI layer, transport layer (like ASP.NET), or (at the minimum) the business layer. Using attributes, like the ones found in ```System.ComponentModel.DataAnnotations``` would make automating the validation logic easier.
In keeping with the DRY principle, the developer should only have to define a rule once. And the best place to define these types of rules are on the POCO object itself. like so:
Simple Example (lines added for clarity):
```
public class Symbol
{
// Used by validation logic but only the max value is support by the EF logic
[StringLength(3, MinimumLength = 3)]
// --- or written this way ---
// Used by validation and EF logic
[Max(3)]
// Used by validation logic (and should be respected by EF, but currently is not)
[Min(3)]
// Used by validation logic (depending on the context, may or may not be used by EF)
[Required]
public string Name {get; set;}
}
```
To implement this correctly today, requires placing this "fixed length" rule in two places. One on the POCO object (as shown above) and the other in a EF specific mapping - to FORCE Entity Framework to do the RIGHT THING, like so:
```
modelBuilder.Entity<Symbol>().Property(e => e.Name).IsFixedLength();
```
Why all the hoops? The less 'custom' mappings (or defining a rule in multiple places) the better!
In summary, (in MHO) there are two problems here:
1. The inconsistent use of attributes. I.e. what attributes EF supports and which properties of these supported attribute it chooses to honor is a mystery. EF touts "by conventions" but in this case it is creating "tribe knowledge". It would have been better NOT to support the StringLength attribute than to only support half of it. At least that way we would know what to expect.
2. Requiring the developer to jump through unnecessary hoops.
Therefore, I'm asking the EF team to better support us developers by add support for both StringLength's MinimumLength __and__ the MinAttribute.