I am use to creating a properties class where I would include all my fields and have to write all the get/set properties then have another Database class where i would make all my database calls.
Properties Class
private int _intCard
public int IntCard
{
set { _intcard = value;}
}
Constructor here
Right now this does not feel like the right approach as I have over 120 properties that I will be dealing with and seems really time consuming to have to write each one of those properties out. I will need to add validation to some of the properties is my reason for choosing this way, i could validate it in the set method. Can anyone suggest an alternative way that I could look into to complete the same result.
********************---------------*******************
So giving the comments I understand my design is flawed that is what I figured coming into this question. I have an idea on how to fix this but do not know if it is the correct way to approach this. I searched for Object Design Principles and read up on that but will need more time to grasp what it is teaching me. For now I would like to know if this approach is the correct way
I am keeping track of applicants name,address,phone,faxnumber,cellphone,altphone,altaddress, same for spouse, and then children, references, company information.....and so on
I am not going to lie I do not understand abstract classes yet in order to implement this if that is the approach I should take I will take more time to learn that but for now was hoping this would be suitable.
Property classes would be as followed
applicant.cs, applicantspouse.cs, applicantcontactinfo.cs, appreferences.cs......
Is this along the lines of what I should be doing?
Thanks again
I can't help thinking your object modelling isn't right here. If you have a class with 120 properties then you've not divided up that object into separate roles/responsibilities etc. I would look at increasing (dramatically) the number of classes you're creating, and that way your solution becomes more manageable.
That won't reduce the number of properties that you have to handle. It may be worth considering immutable objects (do you need to set these properties beyond during construction?), and/or the use of the Builder pattern to aid construction.
Finally, do you need to expose these properties ? A key part of OO is telling objects to do things for you, rather than getting their contents and doing things for them. If you can tell an object to do something for you, you quite likely don't need to expose their (internal) fields.
By reading the comments it looks like you need at least two classes Person, Address something like:
public class Person
{
Guid Id {get; set;}
string Name {get; set;}
// ad infinitum the truely unique things that relate to an Individual
Address BusinessAddress {get; set;}
Address HomeAddress {get; set;}
Person Spouse {get; set;}
}
public class Address
{
Guid Id {get; set;}
Line1 {get; set;}
// ad infinitum all the truly unique things that relate to an address
}
The above is essentially pseudo-code and shouldn't be read as "This is exactly how to do it", I haven't for instance stated whether the properties are private/public/protected or indeed provided a constructor.
But it does show how you can use other classes as properties and in the case of "Spouse" create quite rich and deep object Hierarchies (Spouse could contain addresses and potentially another spouse - circular reference ahoy!) which can be populated and used to make code more readable and separate out the responsibility of the code to encapsulate a "concept/entity/domain" into a single unit who's job it is to be "that specific thing". Probably worth looking at OOP concepts like encapsulation, inheritance and so on (basically the four tenets of OO) here to get a feel for what an object should represent, this link has a brief intro and should help you in deciding how to break out the classes and construct more useful objects.
http://codebetter.com/raymondlewallen/2005/07/19/4-major-principles-of-object-oriented-programming/
In modern c# versions there's a super compact sintax for properties:
public class Properties {
public int IntCard { get; set; }
}
Here c# handles the private variable for you, this way you can avoid a lot of keystrokes. For validation you can use Data Annotations. More info here
Hope it helps
Totally agree with #brian-agnew that if you have that many properties in 1 class then you probably need to do some refactoring as you almost certainly do not have enough separation of concerns.
However even after some refactoring, you will still have the properties, so it would be worth looking at the data validation attributes. For example, here is a walk though of using them with MVC: http://www.asp.net/mvc/tutorials/older-versions/models-(data)/validation-with-the-data-annotation-validators-cs. You could then use auto-implemented properties:
public int IntCard { get; set; }
Please note that this does not address your design issues. If your database is on sql-server, to avoid typing you could use a query like this (please modify for your requirement) to get the property list with datatypes and then copy and paste the results. SQL SERVER DEMO
SELECT 'public ' + CASE DATA_TYPE WHEN 'smallint' THEN 'short'
WHEN 'bit' THEN 'bool'
WHEN 'smalldatetime' THEN 'System.DateTime'
WHEN 'datetime' THEN 'System.DateTime'
WHEN 'date' THEN 'System.DateTime'
WHEN 'uniqueidentifier' THEN 'System.Guid'
WHEN 'varchar' THEN 'string'
WHEN 'int' THEN 'int'
WHEN 'numeric' THEN 'decimal'
ELSE DATA_TYPE END
+ CASE IS_NULLABLE WHEN 'NO' THEN '' ELSE '?' END
+ ' ' + COLUMN_NAME
+ ' { get; set; }' AS def
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_NAME = 'YourTableName'
ORDER BY IS_NULLABLE, ORDINAL_POSITION
Tim,
Based on your edit, you look like you are on the right lines. You should be breaking the properties down into specific items, for example:
public class Person
{
public string GivenName { get; set; }
public string Surname { get; set; }
public ContactInfo ContactInformation { get; set; }
}
public class Applicant : Person
{
public Person Spouse { get; set; }
public List<Person> Children { get; set; }
public List<Reference> References { get; set; }
}
public class ContactInfo
{
[Required]
[DataType(DataType.PhoneNumber)]
public string PhoneNumber { get; set; }
[DataType(DataType.EmailAddress)]
public string EmailAddress { get; set; }
public Address PrimaryAddress { get; set; }
public Address AlternativeAddress { get; set; }
}
So the key points for you here are that
the class are broken down into manageable, reusable chunks
Data Annotations (Required & DataType in the ContactInfo class) are used to validate properties
The properties no longer need explicit private variables
P.S. A bit more info about data annotations: http://msdn.microsoft.com/en-us/library/dd901590(v=vs.95).aspx
Related
Okay, I've seen some similar questions to this, but the answers either confused me or seemed completely over-engineered, so I'd like to ask my own question.
I have a class called Tree, which has an object property from the class Plot, which has an object property from the class Year, which has an object property from the class Series, which has a string property called Id. This is summarized below.
public class Tree {
public virtual Plot Plot { get; set; }
// other properties...
}
public class Plot {
public virtual Year Year { get; set; }
// other properties...
}
public class Year {
public virtual Series Series { get; set; }
// other properties...
}
public class Series {
public virtual string Id { get; set; }
// other properties...
}
Each of these classes corresponds to the table of a database, and properties correspond to foreign key fields (for example, the Trees table has a field called PlotKey, which refers to a record in the Plots table). All I want to do is load all trees from the database whose corresponding Series have the Id "Adrian_2012" or "IPED Sample". I thought this would be a pretty easy taking using the following code:
IList<Tree> trees = session.CreateCriteria<Tree>()
.Add(Expression.Or(
Expression.Eq("Plot.Year.Series.Id", "Adrian_2012")
Expression.Eq("Plot.Year.Series.Id", "IPED Sample")
))
.List<Tree>();
But this is throwing: "NHibernate.Exceptions.GenericADOException : could not execute query". I have tried using Expression.Disjunction, I have tried using Aliases, Restrictions, and SimpleExpressions, and I know that nothing stupid like unmapped properties or misspelled criteria is occurring. The only other thing I've seen that might help is the ISession.QueryOver<>() function, but I get very confused by lambda expressions. Does anyone have a solution for me that would use just a simple CreateCriteria<> statement like that above?
Thanks in advance!
One not nice side of the Criteria queries is, that we have to define associations chain explicitly. I.e. we have to introduce JOIN:
15.4. Associations (cite:)
You may easily specify constraints upon related entities by navigating associations using CreateCriteria().
So to have a JOIN we need syntax like this
var trees = session
.CreateCriteria<Tree>()
.CreateCriteria("Plot", "p")
.CreateCriteria("Year", "y")
.CreateCriteria("Series", "s")
.Add(Expression.Or(
Expression.Eq("s.Id", "Adrian_2012")
Expression.Eq("s.Id", "IPED Sample")
))
.List<Tree>();
Also, check this:
NHibernate - CreateCriteria vs CreateAlias
I'm having a problem with a mapping in Entity Framework.
I have the following classes (simplified):
public class Building
{
public int ID { get; set; }
// *.. snip..* other properties
public Location Location { get; private set; }
}
public class Location
{
public string Street {get; set;}
public Country country {get; set}
}
public class Country
{
public int ID { get; set; }
public string Name { get; set; }
}
Building and Country are entities, they are saved in the database. Location is a value type and should map to the same table as Building.
However, when I map it this way, entity framework wants to map Location to a table as well and is complaining it has no Key. I don't want to give it a key since it belongs to the Building and should not be an entity at all.
I have seen workarounds which say you need to put Country on the Building-class, but that just doesn't feel good (and is semantically just plain wrong).
I'm using Entity Framework 5
Since the release of Entity Framework Core 2, it is now possible to achieve this using owned entities.
Your configuration would look like:
protected override void OnModelCreating(ModelBuilder modelBuilder)
{
// ...
modelBuilder.Entity<Building>().OwnsOne(x => x.Location);
modelBuilder.Entity<Location>().HasOne(x => x.Country);
// ...
}
This way, properties from Location class will be a part of the table Building class is mapped to. This means you will only have tables for Building and Country classes and the Building table will have a foreign key to the Country table.
I know it's been a long since you posted the question, but I thought this answer might be helpful to someone who comes across this question.
In my opinion the Entity Framework shouldn't allow such a case.
I understand that you don't consider the Location as an Entity but adding entity references to complex types doesn't seem like a solid approach either. The relationship of a building to a country is quite straight forward. A building belongs to one country. Thus a building model should include a country id. What would you expect to be mapped?
If you would expect the table Building to have just three columns ID, Street, CountryId and you still want to hold the Location model then you should use the following complex type.
public class Location
{
public string Street {get; set;}
public int countryId {get; set}
}
If however you would expect your Building table to have all the fields from the model Country then that could lead to some tricky situations like what would happen If you wanted to add new fields to the Country model or If you wanted to add other complex types or entities to your Country model according to a new Business Case.
Those cases would mess with the relational concept and would over-complicate your structure without any meaningful reason. (in my opinion of course)
You may mark Location property in Building class with [NotMapped] Attribute.
using System.ComponentModel.DataAnnotations.Schema;
public class Building
{
[NotMapped]
public Location Location { get; private set; }
}
Hope that solves your problem!
I'm building an app using code first and generating the DB.
I can no longer modify the DB so, I can't add/change columns and tables. But the Domain Model (not sure if I'm using the term correctly) requires new properties (that are part of the domain) that can be inferred from the database data, but do not exist explicitly.
My database stores sales info for houses. So I have two tables, Houses and Sales. The tables are related by houseID. Now I want houses to have a property called LastSaleDate, but I can't change the underlying database.
So, How would I properly construct this new property and add it into the appropriate layer? Here is what my poco/entities look like. Just pseudo coded...
[I am trying to learn all I can about the tools and methods I use. I may be completely wrong on all my assumptions and maybe I am to add it to my pocos. If that is the case please explain how that would work]
[Table("HOUSE_TABLE")]
public class house {
//some properties
public int HouseID {get;set;}
}
[Table("SALE_TABLE")
public class sale {
//some properties
public int HouseID {get;set;
public int SaleID {get;set;}
public datetime SaleDate {get;set;}
public virtual House House {get;set;}
}
I almost feel like this would create 2 levels of mapping. Though, I don't believe I've ever seen this done in any code I've seen online.
poco -> AutoMapper?? -> entities -> Automapper -> viewModels
This logic most likely belongs on the Entity. Entities should have both data and behaviour. What you seem to be describing is some behaviour that is exposed as a property. So, you should add a property for the derived value to your entity. By default, if the property only has a getter, then EF will not try to map the value to the database.
For example:
[Table("HOUSE_TABLE")]
public class house
{
//some properties
public int HouseID {get;set;}
public virtual ICollection<Sale> Sales { get; set; }
public DateTime LastSaleDate
{
get
{
return this.Sales.OrderByDescending(s => s.SaleDate).First();
}
}
}
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Locked. This question and its answers are locked because the question is off-topic but has historical significance. It is not currently accepting new answers or interactions.
Everytime I'm looking for AutoMapper stuff on StackOverflow, I'm reading something about ValueInjecter.
Can somebody tell me the pros and cons between them (performance, features, API usage, extensibility, testing) ?
as the creator of ValueInjecter, I can tell you that I did it because I wanted something simple and very flexible
I really don't like writing much or writing lots of monkey code like:
Prop1.Ignore, Prop2.Ignore etc.
CreateMap<Foo,Bar>(); CreateMap<Tomato, Potato>(); etc.
ValueInjecter is something like mozilla with it's plugins, you create ValueInjections and use them
there are built-in injections for flattening, unflattening, and some that are intended to be inherited
and it works more in an aspect type of way, you don't have to specify all properties 1-to-1, instead you do something like:
take all the int properties from source which name ends with "Id", transform the value and set each to a property in the source object with same name without the Id suffix and it's type is inherited from Entity, stuff like that
so one obvious difference, ValueInjecter is used even in windows forms with flattening and unflattening, that's how flexible it is
(mapping from object to form controls and back)
Automapper, not usable in windows forms, no unflatenning, but it has good stuff like collections mapping, so in case you need it with ValueInjecter you just do something like:
foos.Select(o => new Bar().InjectFrom(o));
you can also use ValueInjecter to map from anonymous and dynamic objects
differences:
automapper create configuration for each mapping possibility CreateMap()
valueinjecter inject from any object to any object (there are also cases when you inject from object to valuetype)
automapper has flattening built it, and only for simple types or from same type, and it doesn't has unflattening
valueinjecter only if you need it you do target.InjectFrom<FlatLoopValueInjection>(source); also <UnflatLoopValueInjection>
and if you want from Foo.Bar.Name of type String to FooBarName of type Class1 you inherit FlatLoopValueInjection and specify this
automapper maps properties with same name by default and for the rest you have to specify one by one, and do stuff like Prop1.Ignore(), Prop2.Ignore() etc.
valueinjecter has a default injection .InjectFrom() that does the properties with the same name and type; for everything else you create your custom valueinjections with individual mapping logic/rules, more like aspects, e.g. from all props of Type Foo to all props of type Bar
Since I've never used any of the other tools, I can only talk about AutoMapper. I had a few goals in mind for building AutoMapper:
Support flattening to dumb DTO objects
Support obvious scenarios out of the box (collections, enumerations etc.)
Be able to easily verify mappings in a test
Allow for edge cases for resolving values from other places (custom type->type mapping, individual member mapping, and some really crazy edge cases).
If you want to do these things, AutoMapper works very well for you. Things AutoMapper doesn't do well are:
Filling existing objects
Unflattening
The reason being I've never needed to do these things. For the most part, our entities don't have setters, don't expose collections, etc. so that's why it's not there. We use AutoMapper to flatten to DTOs and map from UI models to command messages and the like. That's where it works really, really well for us.
I tried both and prefer ValueInjecter because it's so simple:
myObject.InjectFrom(otherObject);
That's all there is to know for the vast majority of my injection needs. It can't possibly get more simple and elegant than this.
This is a question I've been researching too, and for my use case, it seems to be valueinjecter hands down. It requires no prior setup to use (may hit performance I guess, although if smartly implemented it could cache the mappings for future invocations rather than reflecting each time), so you don't need to predefine any mappings before using them.
Most importantly however, it allows reverse mapping. Now I may be missing something here as Jimmy mentions that he sees no use case where its necessary, so maybe I have the pattern wrong, but my use case is that I'm creating a ViewModel object from my ORM. I then display this on my webpage. Once the user finishes I get the ViewModel back in as a httppost, how does this get converted back to the original ORM classes? I'd love to know the pattern with automapper. With ValueInjector it is trivial, and it will even unflatten. e.g Creating a new entity
The model created by the entityframework (model first):
public partial class Family
{
public int Id { get; set; }
public string FamilyName { get; set; }
public virtual Address Address { get; set; }
}
public partial class Address
{
public int Id { get; set; }
public string Line1 { get; set; }
public string Line2 { get; set; }
public string TownCity { get; set; }
public string County { get; set; }
public string Postcode { get; set; }
public virtual Family Family { get; set; }
}
The ViewModel (which I can decorate with validators):
public class FamilyViewModel
{
public int Id { get; set; }
public string FamilyName { get; set; }
public int AddressId { get; set; }
public string AddressLine1 { get; set; }
public string AddressLine2 { get; set; }
public string AddressTownCity { get; set; }
public string AddressCounty { get; set; }
public string AddressPostcode { get; set; }
}
The ViewController:
//
// GET: /Family/Create
public ActionResult Create()
{
return View();
}
//
// POST: /Family/Create
[HttpPost]
public ActionResult Create(FamilyViewModel familyViewModel)
{
try
{
Family family = new Family();
family.InjectFrom<UnflatLoopValueInjection>(familyViewModel);
db.Families.Add(family);
db.SaveChanges();
return RedirectToAction("Index");
}
catch
{
return View();
}
}
To my mind, it doesn't get much simpler than that?
(So this begs the question, whats wrong with the pattern that I run into this (and it seems many others do to), that its not seen as of value to AutoMapper?)
However, if this pattern as decscribed, is one you want to use, then my vote is valueinjecter by a country mile.
my first time on the site so apologies if it's tagged incorrectly or been answered elsewhere...
I keep running into particular situation on my current project and I was wondering how you guys would deal with it. The pattern is: a parent with a collection of children, and the parent has one or more references to particular items in the child collection, normally the 'default' child.
A more concrete example:
public class SystemMenu
{
public IList<MenuItem> Items { get; private set; }
public MenuItem DefaultItem { get; set; }
}
public class MenuItem
{
public SystemMenu Parent { get; set; }
public string Name { get; set; }
}
To me this seems like a good clean way of modelling the relationship, but causes problems immediately thanks to the circular association, I can't enforce the relationship in the DB because of the circular foreign keys, and LINQ to SQL blows up due to the cyclic association. Even if I could bodge my way round this, it's clearly not a great idea.
My only idea currently is to have an 'IsDefault' flag on MenuItem:
public class SystemMenu
{
public IList<MenuItem> Items { get; private set; }
public MenuItem DefaultItem
{
get
{
return Items.Single(x => x.IsDefault);
}
set
{
DefaultItem.IsDefault = false;
value.DefaultItem = true;
}
}
}
public class MenuItem
{
public SystemMenu Parent { get; set; }
public string Name { get; set; }
public bool IsDefault { get; set; }
}
Has anyone dealt with something similar and could offer some advice?
Cheers!
Edit: Thanks for the responses so far, perhaps the 'Menu' example wasn't brilliant though, I was trying to think of something representative so I didn't have to go into the specifics of our not-so-self-explanatory domain model! Perhaps a better example would be a Company/Employee relationship:
public class Company
{
public string Name { get; set; }
public IList<Employee> Employees { get; private set; }
public Employee ContactPerson { get; set; }
}
public class Employee
{
public Company EmployedBy { get; set; }
public string FullName { get; set; }
}
The Employee would definitely need a reference to their Company, and each Company could only have one ContactPerson. Hope this makes my original point a bit clearer!
The trick to solving this is to realize that the parent does not need to know about all of the methods of the child, and that the child does not need to know all the methods of the parent. Therefore you can use the Interface Segregation Principle to decouple them.
In short, you create an interface for the parent that has only those methods that the child needs. You also create an interface for the child that has only those methods that the parent needs. Then you have the parent contain a list of the child interfaces, and you have the child point back to the parent interface. I call this the Flip Flob Pattern because the UML diagram has the geometry of an Eckles-Jordan flip-flop (Sue me, I'm an old hardware engineer!)
|ISystemMenu|<-+ +->|IMenuItem|
A 1 \ / * A
| \/ |
| /\ |
| / \ |
| / \ |
| / \ |
|SystemMenu| |MenuItem|
Notice that there is not cycle in this diagram. You cannot start at one class and follow the arrows back to your starting point.
Sometimes, in order to get the separation just right, you have to move some methods around. There might be code that you thought should have been in the SystemMenu that you move to the MenuItem, etc. But in general the technique works well.
Your solution seems quite reasonable.
Another thing to think about is that your objects in memory don't have to exactly match the database schema. In the database you can have the simpler schema with the child properties, but in memory you can optimize things and have the parent with references to the child objects.
I don't really see your problem. Clearly you're using C#, which holds objects as references not instances. This means it's perfectly fine to have cross-referencing, or even self-referencing.
in C++ and other languages where objects are more compositied then you can have problems, which are typically solved using references or pointers, but C# should be fine.
More than likely your problem is that you're trying to follow all references somehow, leading to a circular reference. LINQ uses lazy loading to address this issue. For instance, LINQ won't load the Company or the Employee until you reference it. You just need to avoid following such references further than one level.
However, you can't really add two tables as each others foreign key, otherwise you would never be able to delete any record, since deleting an employee would require deleting the company first, but you can't delete the company without deleting the employee. Typically, in this case, you would only use one as a real foreign key, the other would simply be a psuedo-FK (that is, one that is used as an FK but doesn't have constraints enabled). You have to decide which is the more important relationship.
In the company example, you would likely want to delete the employee but not the company, so make the company->employee FK the constraint relationship. This prevents you from deleting the company if there are employees, but you can delete employees without deleting the company.
Also, avoid creating new objects in the constructor in these situations. For instance, if your Employee object creates a new Company object, which includes a new employee ojbect created for the employee, it will eventually exhaust memory. Instead, pass the objects already created to the constructor, or set them after construction, possibly by using an initalization method.
For instance:
Company c = GetCompany("ACME Widgets");
c.AddEmployee(new Employee("Bill"));
then, in AddEmployee, you set the company
public void AddEmployee(Employee e)
{
Employees.Add(e);
e.Company = this;
}
Maybe a self-referential GoF Composite pattern is an order here. A Menu has a collection of leaf MenuItems, and both have a common interface. That way you can compose a Menu out of Menus and/or MenuItems. The schema has a table with a foreign key that points back to its own primary key. Works with walking menus that way, too.
In code, you need to have references both ways to reference things both ways. But in the database, you only need the reference one way to make things work. Because of the way joins work, you only need to have the foreign key in one of your tables. When you think about it, every foreign key in your database could be flipped around, and create and create a circular reference. Best to just pick one record, in this case probably the child with a foreign key to the parent, and just be done.
In a domain driven design sense way, you can choose to avoid bidirectional relations between entities where it's possible. Choose one "aggregate root" to hold the relations, and use the other entity only when navigation from the aggregate root. I try to avoid bidirectional relations where it's possible. Because of YAGNI, and it will make you ask the question "what was first, the chicken or the egg?" Sometimes you will still need bidirectional associations, then choose one of the solutions mentioned earlier.
/// This is the aggregate root
public class Company
{
public string Name { get; set; }
public IList<Employee> Employees { get; private set; }
public Employee ContactPerson { get; set; }
}
/// This isn't
public class Employee
{
public string FullName { get; set; }
}
You can enforce foreign keys in the database where two tables refer to each other. Two ways come to mind:
The default child column in the parent is initially null and is only updated once all the child rows have been inserted.
You defer constraint checking until commit time. This means you can insert first the parent with an initially broken reference to the child, then insert the child. One problem with deferred constraint checking is that you can end up with database exceptions being thrown at commit time which is often inconvenient in many db frameworks. Also, it means you need to know the primary key of the child before you insert it which may be awkward in your setup.
I've assumed here that the parent menu item lives in one table and the child in a different table but the same solution would work if they are both in the same table.
Many DBMS's support deferred constraint checking. Possibly yours does too although you don't mention which DBMS you are using
Thanks to all who answered, some really interesting approaches! In the end I had to get something done in a big hurry so this is what I came up with:
Introduced a third entity called WellKnownContact and corresponding WellKnownContactType enum:
public class Company
{
public string Name { get; set; }
public IList<Employee> Employees { get; private set; }
private IList<WellKnownEmployee> WellKnownEmployees { get; private set; }
public Employee ContactPerson
{
get
{
return WellKnownEmployees.SingleOrDefault(x => x.Type == WellKnownEmployeeType.ContactPerson);
}
set
{
if (ContactPerson != null)
{
// Remove existing WellKnownContact of type ContactPerson
}
// Add new WellKnownContact of type ContactPerson
}
}
}
public class Employee
{
public Company EmployedBy { get; set; }
public string FullName { get; set; }
}
public class WellKnownEmployee
{
public Company Company { get; set; }
public Employee Employee { get; set; }
public WellKnownEmployeeType Type { get; set; }
}
public enum WellKnownEmployeeType
{
Uninitialised,
ContactPerson
}
It feels a little cumbersome but gets around the circular reference issue, and maps cleanly onto the DB which saves trying to get LINQ to SQL to do anything too clever! Also allows for multiple types of 'well known contacts' which is definitely coming in the next sprint (so not really YAGNI!).
Interestingly, once I came up with the contrived Company/Employee example it made it MUCH easier to think about, in contrast to the fairly abstract entities that we're really dealing with.