Development Good Practices - Good-Architecture-And-Solution-Structure
Development Good Practices - Good-Architecture-And-Solution-Structure
Create tables with good names (singular and often similar to domain update(model object)
model class names) delete(model object)
Use good column names (singular, with only standard abbreviations
the extra "crud" methods
in the names
`deleteById(int id) (or other name for key column: deleteByAccount‐
Normalize DB to 3rd normal form
Number, etc.) - findByPartOfName(String partOfName) (or other
Add foreign key and unique constraints searchable attribute)
Use IDENTITY (autogenerated keys) on surrogate key columns (or other
findByPartOfName(String partOfName)
Implement robust cascading update/delete choices on foreign key searchable attribute)
constraints for referential integrity transactions wherever you need to do two or more operations as a
Add good denormalization choices for speeding up working with the unit: e.g.
DB read inventory count and place order if product is available
Add a unique database login (preferable Active Directory account for exception message (e.g. "Unknown error. Account number 354 was
Windows authentication or non-SA for SQL logins) with only minimal not deleted.").
permissions necessary (e.g. dbreader/dbwriter) on the relevant try-catch code which rethrows any exceptions that happen while
DB/tables interacting with the database, with a message about what was
attempted when the exception happened plus the original exception.
MODEL LAYER
Mimic the database tables' structure with regards to naming and data
types (often one model class per table)
Add a good toString() method to your model classes for debugg‐
ing/visualizing object state
Use good encapsulation (especially of collections) so you can
change the underlying data structure without changing the interface
Code good constructors which ensure you can't instantiate objects in
an invalid state
insert(model object)