Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Inheritance Problem 1

Status
Not open for further replies.

arnie789

Programmer
Sep 29, 2010
1
0
0
GB
Hi,

I have to extend a type to add an extra property then convert back to the original type before inserting into the database. I have this working but my solution seems like a hack and there must be a better way. Here's what i have:

public class Item
{
public string Property1 { get; set; }
public string Property2 { get; set; }
...
}

public class SelectedItem : Item
{
public bool IsSelected { get; set; }

public SelectedItem(Item item)
{
Property1 = item.Property1;
Property2 = item.Property2;
...
IsSelected = truel
}
}

Now i can take a list of items and convert them to a list of SelectedItem by saying:

var selectedItems = items.Select(i => new SelectedItem(i)).ToList();

Is not there not a way to remove the constructor since it inherits from Item anyway.

I then have the reverse problem i need to loop over the selected items and insert any in to the database that are selected (IsSelected = true). Here's my code so far:

foreach (var selectedItem in selectedItems)
{
if (selectedItem.IsSelected)
_repository<Item>().Insert(new Item() { Property1 = selectedItem.Property1, Property2 = selectedItem.Property2 ... });
}

Again this seems somewhat of a hack since it has to create a new Item setting each property. I tried doing:

foreach (var selectedItem in selectedItems)
{
if (selectedItem.IsSelected)
_repository<Item>().Insert(selectedItem);
}

While this compiles my application throws an error on Insert that it would like an item of type Item and not SelectedItem.

Appreciate your support.
 
it looks like you want your view model to inherit from your domain model. I consider this a design flaw. instead i would have a separate view model and domain model and map between the 2. a framework like automapper makes that very simple.

in that instance you would have
Code:
class SelectedItem
{
  public string Property1{get;set;}
  public string Property2{get;set;}
  public bool Selected{get;set;}
}

class Item
{
  public string Property1{get;set;}
  public string Property2{get;set;}
}
convert one to the other and back again as needed. something else to consider is that a view model isn't a copy of the domain model. the view model works with the UI. properties match directly to UI controls. the domain model represents the business work flow, independent of any UI needs. for example you may have a domain like this
Code:
class Order
{
   public IEnumerable<OrderLine> Lines{get; set;}
   public DateTime OrderDate {get; set;}
}
class OrderLine
{
   public Product Product{get; set;}
   public int Quantity {get; set;}
}
Code:
class OrderSummary
{
   string DateOrdered {get;set;}
   double Total {get;set;}
   int UniqueProducts {get;set;}
}

class ChangeOrderDate
{
   DateTime NewDate {get;set;}
}
manual mapping would look like this
Code:
new OrderSummary {
   DateOrdered = order.OrderDate.ToString("F"),
   Total = order.Lines.Sum(line=>line.Total()),
   UniqueProducts = order.Lines.Distinct(line=>line.Product).Count()
};
Code:
Orders.Get<Order>(id).OrderDate = changeOrderDate.NewDate;
automapper removes some of the redundancy and heavily favor convention over configuration.

all that said, my original statement about the view model inheriting from the domain model is the crux of the issue.

Jason Meckley
Programmer

faq855-7190
faq732-7259
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top