I am currently having a 'frank exchange of views' with a fellow lead tech on how to establish a common architecture .. I suggested the standard seperation of Component or Service based layers, Entity layer, and Data Access layer. Everyone was happy and that's been adopted.
I like code generation... saves on reptitive tasks, and can implement patterns in a reliable way. So, I demonstrated a way of generating objects using the standard class designer in VS 2005, then, using snippets, quickly adding attributes that specified primary keys, relationships between these entities combined with a simple utility that used reflection to obtain information about exposed properties, and within 10 minutes had generated a database schema with referential integrity, a data access layer, entities that contained basic validation rules derived from the database schema, and a customisable component layer. All built on top of the Enterprise Library with associated caching, configuration, logging and exception handling... basically codesmith and .NetTiers with my own additions.
My coworker wants to create multiple levels of inheritance, rather than my approach that would would use composition with interfaces, a Manager and Processor pattern to remove the inheritance dependcies.
Basically, he wants to use 'pure OO' to design what I consider to be an unneccessarily complex Domain, and then use NHibernate to map persistence, and bolt on bit of CSLA.Net for a validation rules engine, he hasnt quite made it clear how he will handle other aspects such as logging and exception management.
I do also prefer the freedom to design my objects seperate from the database structure they will reside in, but in practical terms, when most of our applications are data driven, I dont see the downside of 1) getting the database schema right and 2) using that as the basis for an object model, which can then be customised.
Bearing in mind what is coming from MS in terms of LINQ, DLINQ and Entity Data Mapper, its seems to follow a similar pattern... design your data storage... then extrapolate your entity model from these schema... amend as required, and use DLINQ for persistance, with LINQ for querying object graphs in memory.
Anybody any comments on this?
I like code generation... saves on reptitive tasks, and can implement patterns in a reliable way. So, I demonstrated a way of generating objects using the standard class designer in VS 2005, then, using snippets, quickly adding attributes that specified primary keys, relationships between these entities combined with a simple utility that used reflection to obtain information about exposed properties, and within 10 minutes had generated a database schema with referential integrity, a data access layer, entities that contained basic validation rules derived from the database schema, and a customisable component layer. All built on top of the Enterprise Library with associated caching, configuration, logging and exception handling... basically codesmith and .NetTiers with my own additions.
My coworker wants to create multiple levels of inheritance, rather than my approach that would would use composition with interfaces, a Manager and Processor pattern to remove the inheritance dependcies.
Basically, he wants to use 'pure OO' to design what I consider to be an unneccessarily complex Domain, and then use NHibernate to map persistence, and bolt on bit of CSLA.Net for a validation rules engine, he hasnt quite made it clear how he will handle other aspects such as logging and exception management.
I do also prefer the freedom to design my objects seperate from the database structure they will reside in, but in practical terms, when most of our applications are data driven, I dont see the downside of 1) getting the database schema right and 2) using that as the basis for an object model, which can then be customised.
Bearing in mind what is coming from MS in terms of LINQ, DLINQ and Entity Data Mapper, its seems to follow a similar pattern... design your data storage... then extrapolate your entity model from these schema... amend as required, and use DLINQ for persistance, with LINQ for querying object graphs in memory.
Anybody any comments on this?
Comment