Linq-to-SQL DAL on a Windows Forms project

I just started out a new job as a C# programmer on .NET 3.5. My manager gives me total independence on how I build my modules, which is generally a good thing, but there are minuses too. Having too much "freedom" tends to make me wander to places you wouldn't have if you had some strict guidance.

My project involves many simple forms and reports, usually one table for each form, sometimes I have a 1-to-1 or 1-to-Many relations on a specific form. Also, my business objects are not complicated for now, every table on the database maps to on exactly one business object.

So, I did my research and decided that for my DAL which isn't too complicated I'll be using a Linq-to-SQL within simple Repositories classes as it provides me with a simple ORM mappings of objects. Also. in .NET 3.5, I felt it's my best option (you are more than welcome to correct me if I'm wrong i.e if you can achieve ORM advantages with vanilla ADO.NET).

I then decided that I'll be using an MVP pattern to tie up my layers, giving me a well de-coupled UI/Business Logic. Having said all that, theory worked perfect but soon as I started with my first module many questions arise. I don't want to make this question too general so I'll give a real life example and explain my confusions once at a time, trying to keep it as concise as I can.

Simple module example:

I have 2 forms, Main form which presents a Person details, this form has a button that when you click a sub-form will popup with that person Children.

Table Person: id(PK),name
Table Children: id(PK),name,parent

Corresponding to those tables I have the following model classes:

Person Class

```
[Table(Name = "Person")]
public class Person
{
public Person()
{
_years = new EntitySet(OnYearAdded, OnYearRemoved);
_children = new EntitySet(OnChildrenAdded, OnChildrenRemoved);
}

[Column(Name = "ID", IsPrimaryKey = true, IsDbGenerated = true, CanBeNull = false)]
public int PersonID { get; set; }

Not going to review all that, just going to focus on one aspect: your table structure.

Edit: ugh, now I read your comment (which was posted while I was doing this review) and most of my review is irrelevant. Still, my point remains: this is really bad database design.

Person

-
Looking at the Person class I have to wonder: what if someone moves?

-
Having both FullName and the fields FirstName and LastName is just asking for trouble.

-
Why name a field PersonCode? You're already in the table Person, so we know this field Code is related to the Person. Just name it Code.

PersonChildren

-
PersonChildren is a bad name for a class, since it is a plural. This class will describe one child, not multiple.

-
Along those lines: PersonID is an "unnatural" name for a field I'd expect to be named ParentID.

-
Moreover is a Child not a person? Isn't there a case possible where a Child will also be a Person, i.e. someone who'll receive custody benefits but also has to pay them?

-
Wouldn't it make more sense to have a Person class, and then both a Parent and a Child class which link to that class for data like name and date of birth?

Some small remarks:

-
Don't use Hungarian notation, it's against the rules: iYear. It's a bad idea anyway.

-
MartialPanelVisable contains two spelling errors.

StackExchange Code Review Q#91574, answer score: 2