c# - Complex domain model based on companies and not users -
i have few different types of companies can access web application e.g
different types of companies:
client supplier agent
each have own table in database, linked main table company stores common data e.g. address, tel, email, typeofcompany fk relevant table (client etc.)...
what best way handle oo throughout app?
i like:
public class companydto { public int id {get;set;} public string name {get;set;} public address address {get;set;} public string type {get;set;} //type of company //etc... }
then inherit class , add aditional properties e.g.
public class clientdto : companydto { public string key {get;set;} public address billing {get;set;} }
however finding problematic @ times example
- supplier user wants access: allcompanies, - show list of companies
- then user supplier company wants view specific companies detail, if client need show clientdto or supplierdto? in instance want show specific companies full details
what best way handle this?
e.g. getcompanybyid(int companyid);
or getclientbyid(int clientid);
type of object should return in both instances, presuming want client details in both instances...
funny how databases don't understand oo practices derivation, aggregation, , encapsulation. unfortunate failing still part of overall referred "database impedance mismatch".
what attempting common enough there several solutions...
firstly there choice of data model stored. there 3 possibilities.
- split tables have done.
- declare fields derived types in same table.
- use blob field (json/xml/whatever) house uncommon fields.
secondly there issue bring up, requesting data database. centered around request of list of 'common' base type , how access uncommon fields don't share. again there several possibilities.
- when listing base type common fields returned. subsequent queries issued one-off lazy load other fields.
- when listing base type other tables needed outer joined main table ensure fields available instantiate object model fully.
- when listing base type, multiple result sets returned, 1 each 'sub type' table may needed results. client pieces records building object model until complete.
not exhaustive list, start. prefer avoid data models 1 describe reason. preference have data model define union of fields (model #2), , use business layer determine properties exposed, validated, required, etc. have used model #3 above, using blob fields multiple values, , works enough depending upon need. downside model #3 on #2 not able query or sort on fields. either approach still needs business logic layer involved know data expose.
remember databases stupid, treat them such , along well. (note: advice not work on people, databases)
Comments
Post a Comment