Using Models and Entities in MVP pattern

Question

I'm a beginner in MVP design pattern and In a MVP triad, I have

Model - AdvanceInfo

View - AdvanceForm

Presenter - AdvancePresneter

and Entity class Advance as follows.

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

So Should my model be as follows...

class AdvanceInfo 
{
 public int AdvanceID { get { return Advance.AdvanceID; } }
 public decimal AdvanceAmount { get { return Advance.AdvanceAmount; } set { Advance.AdvanceAmount = value; } }
 public DateTime AdvanceEnteredDate { get { return Advance.AdvanceEnteredDate; } set { Advance.AdvanceEnteredDate = value; } }
 public int EmployeeID { get; set; }
 public string NameWithInitials { get; set; }
 public string BankAccountName { get; set; }
 public string BankAccountNumber { get; set; }
 public Advance Advance = new Advance();
}

or else...

class AdvanceInfo 
{
 public int AdvanceID { get; set; }
 public decimal AdvanceAmount { get; set; }
 public int EmployeeID { get; set; }
 public string NameWithInitials { get; set; }
 public string BankAccountName { get; set; }
 public string BankAccountNumber { get; set; }
 public DateTime AdvanceEnteredDate { get; set; }
 public DateTime AdvanceProcessDate { get; set; }
}

Note: * I'm using entity class Advance as an aggregate class in DeductionInfo class as well. * I'm not using any frameworks like EF. Only VS. (Since this is academic purpose project)

I hope my question is clear; actually what I want to know is how entity classes are used to build model? or else can we use Model classes alone?

• Marc-Andre: I'm a "noob" in .net, what VS stand for ?
• CAD: I meant Visual Studio ;)

Answer 1

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:

YUML diagram: [Advance]1-0..1>[AdvanceInfo]|[Advance]1-0..1>[DeductionInfo]

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

YUML diagram: [Advance]<>->[AdvanceInfo]|[Advance]<>->[DeductionInfo]

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.

• CAD: Nice answer and I think I got the point. but I'm little confused-> People would view a POCO as a plain old class that doesn't try to be part of the trendy pattern set, just like my Advance class. But in your example classes (used inheritance) no POCO classes and you favored inheritance over composition in this case. Am I correct?
• Mathieu Guindon: Yeah, just presenting it as a possibility though. Like I said I'd go with the else snippet ;) I often use inheritance with my POCO's, I find it useful for stuffing Id, DateCreated and DateUpdated properties (I call that type EntityBase). I'm not sure I'd use it for anything else, like properties that are common to a group of entities. Perhaps I should put that in the answer as well...
• CAD: One thing to clarify. In your AdvanceInfo class derived from AdvanceBase, it has properties EmployeeID, EmployeeName etc. which are actually belonged to Employee class. So don't we have to derived from That class too without re declaring same? Is that the best practice?
• CAD: ALSO in all the places we use EmployeeID property, should we derive it from Employee class? Thank you!