Home
brrrdog edited this page Jun 21, 2017
·
6 revisions
- Almost all interfaces work on a single elemental type - the string.
- When an interface prompts for a dollar amount the first business rule we have is to ensure that the string the user typed in something that is convertible to a decimal
- Validation of even non-string types are often done with string functions - regular expressions, and string length for example
- But current patterns split that rule (SoC) into a category away from a "business rule"
- Input validation vs model validation in MVC (data annotations, idataerrorinfo)
- Binding validation vs IDataErrorInfo in WPF/MVVM
- Why do we do this?
- It's not because we can't logically consider this first rule is a business rule - it's because of a limitation with our choice of programming language or tool (DD-SoC)!
- A "decimal" c# type cannot store input like "blah blah" - yet it's still something a user can try to do.
- Dual Storage
- We address this problem by storing it's values in both the native exposed type and a backing string type. This allows the initial conversion to be considered a business rule and avoid an artificial SoC.
- Business rules are written right where you'd expect to find them
- No attribute definitions to track down
- No need to track down entirely separate existing attributes (built in attributes are all available with "Assert" and extension methods can be written for custom rules
- Regular code so it's not tied to one particular stack (ie ComponentModel attributes are not well supported outside of MVC)
- Written in a format that non-programmers can read
- Taggable (IdentifiedBy) so that code can be associated to the specs defined it.
- Attributes are very limited
- Do not support generics, thus this limits them to supporting only simple types
- The end result are simple poco classes that can be used anywhere from mvc, to wpf, to wcf services.
- While it is possible to use MVC models with the componentmodel attributes in WPF and WCF, there currently no out of the box support to do ad-hoc validation.
- Adaptable messaging depending on the interface mode.
- Objects and properties have both a friendly name and a system name so that messaging is better suited for the environment in which the object is currently being used (ie MVC UI vs WCF).
- Often architecture decisions are made sighting separation of concerns. However, why do those concerns need to be separated?
- SoC will start with natural divisions (data storage vs "logic") but eventually you get to splitting hairs. Do we need to split our lungs into two different devices for taking in O2 and letting out CO2? No, because the concern is really one in the same. It just needs a different view of the concern like - "gas exchange"
- So where do we get this hair splitting from?
- Our chosen tool or language has a deficiency that doesn't allow us to structure our code in a more logical fashion, so we invent a new division
- Why don't we instead address the deficiency instead of making up a new "concern"?
- There are multiple aspects of separation, both physical and logical. Location, Domain, Task, ETC. Why is the physical separation always given precedence?
- Is a unique constraint in a database not a business rule?
- Class and property has both a system name, ie FirstName, and a human name, ie "First Name", so that error messages can match the interface type (WCF vs Web UI for example).