C#•14mo ago

How to prevent nulls using this approach for Object Initializers?

In C# I have this class:

using System.Diagnostics.CodeAnalysis;
using System.Net.Mail;

namespace Domain.Customers;

public class EmailAddress
{
    private MailAddress email;

    public EmailAddress()
    {
        // Default constructor so I can use object initializer.
    }

    [SetsRequiredMembers]
    public EmailAddress(string email)
    {
        Email = email;
    }
    public required string Email
    {
        get => email.ToString();
        set => email = new MailAddress(value);
    }

}

using System.Diagnostics.CodeAnalysis;
using System.Net.Mail;

namespace Domain.Customers;

public class EmailAddress
{
    private MailAddress email;

    public EmailAddress()
    {
        // Default constructor so I can use object initializer.
    }

    [SetsRequiredMembers]
    public EmailAddress(string email)
    {
        Email = email;
    }
    public required string Email
    {
        get => email.ToString();
        set => email = new MailAddress(value);
    }

}

As you can see I have two constructors, when using object initializers I need to use one of them. I like using object initializers using no constructor aka the default constructor but because I added it there is no default so I added it.

But now the problem is that people can call

new EmailAddress()

new EmailAddress()

without passing an email and it can stay null that way?
How can I still be able to have an empty constructor so I can use object initializers without having the risk somoene calls

new EmailAdress();

new EmailAdress();

Angius•10/21/24, 8:30 PM

The property is

required

required

, so it should enforce it being set during initialization

MODiX•10/21/24, 8:31 PM

Angius

REPL Result: Failure

Exception: CompilationErrorException

Compile: 459.912ms | Execution: 0.000ms | React with ❌ to remove this embed.

Angius•10/21/24, 8:31 PM

As you can see, a compile error

Jiry_XDOP•10/21/24, 8:32 PM

Oh so they can't call the empty constructor witouth a initializer that sets the email?

Jiry_XDOP•10/21/24, 8:32 PM

Thanks

Jiry_XDOP•10/21/24, 8:32 PM

Coming from java its a bit getting used to the initializers and auto setters and getters but I am getting the hang of it

AAngius As you can see, a compile error

Jiry_XDOP•10/21/24, 8:44 PM

Another related question, in EF Core I can do:

This is in Customer.cs entity.
I guess EmailAddress is then not getting stored to the db because it is not mapped. I don't need it mapped I just need to store it as a string.

What would be a clean way to do this?

Angius•10/21/24, 8:46 PM

EF entities should only contain what the table is supposed to contain

Jiry_XDOP•10/21/24, 8:47 PM

Right, so I want to get the value out of EmailAddress string and store that.
(I read about primitive obsession, ... that is why I am trying it this way)

Angius•10/21/24, 8:48 PM

Use a converter, or something like Vogen that comes with such converters

Jiry_XDOP•10/21/24, 8:49 PM

Hmm I'll look into that, thanks

333fred•10/21/24, 10:33 PM

Is there a particular reason you're including both of those constructors? It seems a bit weird

AAngius Use a converter, or something like Vogen that comes with such converters

Jiry_XDOP•10/22/24, 9:40 AM

This worked great. I used implicit operators and ef conversion

3333fred Is there a particular reason you're including both of those constructors? It see...

Jiry_XDOP•10/22/24, 9:42 AM

Some code used a constructor but I made a new class and only wanted to change the class name by the code. Therefore I added the name constructor. To still be able to use object initializers I added the second empty constructor.

JJiry_XD Some code used a constructor but I made a new class and only wanted to change th...

333fred•10/22/24, 3:35 PM

That doesn't seem like a great reason. I'd do just one or the other

3333fred That doesn't seem like a great reason. I'd do just one or the other

Jiry_XDOP•10/22/24, 3:35 PM

True, laziness is the better reason there

Jiry_XDOP•10/22/24, 3:35 PM

I didn't want to alter the code

Jiry_XDOP•10/22/24, 3:36 PM

Anyways may I thank you both for your feedback and help

Jiry_XDOP•10/22/24, 3:36 PM

I really appreciate it