My particular application is an ASP.NET MVC app using Entity Framework.
I have an object Entity0 which contains a reference (* to 1) to Entity1...
public class Entity_0
{
public int ID { get; set; }
public int Entity_1_ID { get; set; }
public Entity_1 Entity_1 { get; set; }
}
I also have some logic in Entity_0, however this logic requires that Entity_1 not be null...
public Entity_2 GetEntity_2()
{
return new Entity_2() { Number = Entity_1.Value * 10 };
}
When a new instance of Entity_0 is created via model binding in the controller, the Entity_1_ID property is set, however the Entity_1 navigation property remains null until it is persisted to the database.
I need to call GetEntity_2() and save Entity_0 and Entity_2 to the database as a single unit of work. Right now this means that I have to manually retrieve Entity_1 out of the repository and assign it to Entity_0 before calling the function.
The other option I considered would be to make Entity_1 a parameter of the GetEntity_2 method, however any other time that method is called Entity_1 will not be null so it would be redundant to require a parameter.
So obviously everything is working right now, but my question is whether or not I am violating some OOP design rule by either a) having a method that could throw a null reference exception or b) specifying a method parameter that should only be used some of the time.
Having to manually assign the navigation property is really bugging me. I'm hoping some of you have some suggestions on how I can improve this.
Thanks!