c# - Specific entity objects for Add and Update methods in a repository -

i'm trying come way design repository adding , updating accepts exact amount of data/properties can add/update.

i have following design:

public interface iproduct {     int id { get; set; }     string name { get; set; }     decimal price { get; set; }     datetime created { get; set; }     datetime updated { get; set; } }  public interface iproductrepository {     void add(iproduct product);     void update(iproduct product);     iproduct get(int id);     ienumerable<iproduct> getall(); } 

however, created , updated properties not want modified outside of database. id not relevant when adding either, tried following:

public interface iproductadd {     string name { get; set; }     decimal price { get; set; } }  public interface iproductupdate {     int id { get; set; }     string name { get; set; }     decimal price { get; set; } } 

and updated repository accordingly:

public interface iproductrepository {     void add(iproductadd product);     void update(iproductupdate product);     iproduct get(int id);     ienumerable<iproduct> getall(); } 

now relevant properties present in each individual method.

i create class implements product interfaces:

public class product : iproduct, iproductadd, iproductupdate {     public int id { get; set; }     public string name { get; set; }     public decimal price { get; set; }     public datetime created { get; set; }     public datetime updated { get; set; } } 

so question is: right way this?

my thoughts:

i have opted change add , update methods on repository accept every bit of product data parameters, such update(int id, string name, decimal price), out of hand when amount of information product holds increases.

my current solution involves repetition. if product should hold description property, have specify in different 3 interfaces. let interfaces implement each other solve this...

public interface iproductadd {     string name { get; set; }     decimal price { get; set; }     string description { get; set; } }  public interface iproductupdate : iproductadd {     int id { get; set; } }  public interface iproduct : iproductupdate {     datetime created { get; set; }     datetime updated { get; set; } } 

...but in trouble if iproductadd have iproductupdate shouldn't have.

related problem: let's want put products in categories, , have access category directly on each product.

public interface icategory {     int id { get; set; }     string name { get; set; }     string description { get; set; } }  public interface iproduct {     int id { get; set; }     string name { get; set; }     decimal price { get; set; }     datetime created { get; set; }     datetime updated { get; set; }     icategory category { get; set; } } 

when change product, want specify id of category (since i'm adding/updating relationship, not category itself):

public interface iproductadd {     string name { get; set; }     decimal price { get; set; }     int categoryid { get; set; } }  public interface iproductupdate {     int id { get; set; }     string name { get; set; }     decimal price { get; set; }     int categoryid { get; set; } } 

this results in following implementation:

public class product : iproduct, iproductadd, iproductupdate {     public int id { get; set; }     public string name { get; set; }     public decimal price { get; set; }     public datetime created { get; set; }     public datetime updated { get; set; }     public icategory category { get; set; }     public int categoryid { get; set; } } 

looking @ that, use category.id or categoryid? not ideal, imo.

so guess see problems no matter how this. picky? looking @ wrong?

should separate things because different things (eg. [the entity] / [add entity parameters] / [update entity parameters])?

i think over-complicating things while not separating layers properly. in opinion, first 2 classes how should done.

from understand, whole issue not want created , updated properties modified incorrectly. however, mixing data , business concerns. saying product's created date should set upon product being created part of business logic of creating new product, , saying product's updateddate should updated when x , y occur part of logical process of updating product's data. same type of process validating properties of product valid, user authorized, etc.., of business process concerns, not data storage concerns.

your repository should solely part of data layer, it's concern how retrieves requested product database, how updates product in database, or creates product in database. that's it.

you need dedicated business layer handles business logic adding or updating product's information. call method in layer name , price of product want add, , in method perform validations want perform, determine if user authorized making these edits, , setting createddate or updateddate if it's warranted. method pass product entity repository save in database.

separating out logic in manner make easier when want change logic on how things such updateddate managed (maybe want actions change date not actions). if try , handle of in repository/data layer, become overwhelming , confusing when away trivial use cases.

one other point. iproduct business entity, means don't have expose presentation layer @ all. therefore, if not want risk developer touching properties, can use mvc architecture calls viewmodels. essentially, these data structures used on presentation layer, , business layer can translate these viewmodels actual business entities.

so example, have:

public class productviewmodel {     int id { get; set; }     string name { get; set; }     decimal price { get; set; }     int categoryid { get; set; } } 

your presentation layer pass filled out productviewmodel business layer's addproduct() or updateproduct() methods, retrieve database's iproduct entity 1 specified , use productviewmodel determine how update (or create new) database entity. way, never expose 2 datetime properties still have full control on how , when set.