I am not very good at C# so there might be something that I missed, but if it was like this in C++, Java, Ruby, Python or any other language that I know, I would never design it like this.
The name "Person" is not what I would choose for a class with this interface. The name is too generic.
Either you make a class whose name, interface and functionality reflect the role that the person has in the system, or you make the "Person" instances be minimal objects and have other objects for roles and/or relations that refer to them.
Second... The address fields are much too restrictive. I would put the fields inside an "Address" class and add fields for "state" and "country".
Third, it would also be good to have some kind of validation, so that you don't "save" empty instances. Put validation of addresses inside the "Address" class.
I would also make "save()" a virtual member function with basic functionality in a superclass.
When dealing with resources outside your program -- and persistent storage is outside your program -- then you must also be able to handle that the operation could fail. At the very least, make "save()" return an error code, but it might be more appropriate in this context to thrown an exception.
Anyway.. This is from an example, so some may be excused -- if they are outside the point of the example. If this code snippet had been at the centre of the example, then it would have been more serious.
