Refining the model
At this point you should have a basic set of entities that reflect the data to be stored. But before we move on, it’s a good idea to review the sketch of the UI that’s serving as our specification to see if there is any additional functionality that it would be useful to inlcude in the model.
If you look back to the sketch of the UI you’ll see that there are two places where the application is doing more than simply binding data. You’ll need to make some decisions about these:
On Your Own
It’s only fair to warn you that whether a given piece of functionality lives in the model, the business layer, or is rightfullly considered part of the user interface can be (and often is) a contentious subject, and there are hardly ever clear answers. (This is, after all, software development, and the answer to most questions is “It depends”.)
In this case, the only person you need to argue with is yourself, so you’ll need to decide whether to handle ingredient formatting and recipe search in the model or in some other layer of the application.
If you decide to put them in the model, then now’s the time to do it.
What I’d Do
My basic rule of thumb for these situations is that if some given piece of functionality could reasonably be pushed to a stored procedure in the database, then I’ll put it in the model.
In this specific case, the formatted Ingredient seems like creating a full name from a person’s first and given names, and it’s likely to be needed elsewhere in a full system. I’d add an unmapped property to the RecipeIngredient class to handle that.
The search functionality isn’t as straightforward, partly because it’s not clear from the sketch exactly how it’s supposed to work. (And it looks as though that could get very complicated very quickly.) What I think I’d do here is implement some basic search functionality, FindRecipesByName() for example, in the model, and leave everything else to other parts of the application.