Using Models and Entities in MVP pattern
It's not clear exactly what you're referring to as Model classes, I think you're over-thinking it.

I'd go with the else snippet, the POCO (Plain Old CLR Object) that does nothing but exposing auto-properties. The snippet that exposes a public Advance field doesn't look right. Do not expose public fields; a class should expose properties, not fields.

Your remark about only using VS isn't clear either: if you're not using EF, that's fine, but this means your data access code is using some data access library - Visual Studio isn't one, it's your IDE; if you're using things under System.Data, you're using ADO.NET.

If I understand correctly what you're doing, you have a bunch of tables/entities that have columns/properties in common, and you're wondering if composition would be better than repeating the properties on all classes. You forgot an option: inheritance.

Composition is normally favored over inheritance, but in the case of POCO classes composition can greatly complicate matters, and if you're instantiating your POCO's from an SqlReader it doesn't really matter how that's done, since you completely own the process.

Things are different with EF - composition would lead to a database model similar to this:



With inheritance, you have this (I hope I got the UML right):



Which involves 3 classes, but works off only 2 tables: Advance isn't really an entity, it's just a base class with properties that are common to DeductionInfo and AdvanceInfo.

Hence, if what you intend to do is to model 2 tables, I'd do this:

public abstract class AdvanceBase
{
    public int AdvanceID { get; set; }
    public decimal AdvanceAmount { get; set; }
    public DateTime AdvanceEnteredDate { get; set; }
    public DateTime AdvanceProcessDate { get; set; }
}


The class is made abstract, to enforce the concept that such a class shouldn't be instantiated and serve as a base class for derived types instead:

public class AdvanceInfo : AdvanceBase
{
    public int EmployeeID { get; set; }
    public string NameWithInitials { get; set; }
    public string BankAccountName { get; set; }
    public string BankAccountNumber { get; set; }
}


The AdvanceInfo class inherits the AdvanceID and everything else from AdvanceBase, so you don't need to specify them again.

Then you'll have:

public class DeductionInfo : AdvanceBase
{
    /* DeductionInfo members */
}


And here also, the class will inherit the AdvanceBase members so you only need to code the DeductionInfo-specific members in that class.

And if/when you switch to EF, you can reuse the exact same POCO classes as entities, without changing anything.

Side note, I think the naming of the classes is somewhat bad - I'd call AdvanceInfo just Advance, and DeductionInfo would be simply Deduction.