Timeline for Pattern Against Anemic Domain Model
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Nov 24, 2013 at 0:43 | history | edited | Malachi | CC BY-SA 3.0 |
added some formatting
|
| Jan 18, 2012 at 8:28 | history | tweeted | twitter.com/#!/StackCodeReview/status/159552703712854016 | ||
| Jan 31, 2011 at 17:21 | comment | added | James | I see two mocking strategies: 1) separate Employee interface from implementation so you can mock Employee and 2) mock EmployeeService inside Employee used in static finders. Niether are hindered from the use of static finder methods. | |
| Jan 31, 2011 at 13:48 | comment | added | Brad Cupit | Also, unless you're using a very nice ORM (meaning, if you'll have any code that is using SQL directly, I would put that in a DAO, and have your object model use the DAO. | |
| Jan 31, 2011 at 13:47 | comment | added | Brad Cupit | The static method introduces tight coupling, which can make unit testing difficult (you won't be able to use a mock Employee, for example). Ruby can get away with it because it is so dynamic (a test can change the Employee class to MockEmployee at runtime) | |
| Jan 30, 2011 at 19:36 | comment | added | James | I disagree with the notion that static methods for finders is bad and that "Employee should not know about keeping records of Employee." Those two patterns are how modern ORM tools like ActiveRecord(Ruby) and GORM(Groovy) do it. Besides, having Employee now how to insert/update/delete itself is classic EAA Active Record pattern. See an example of GORM for what I mean: grails.org/doc/1.0.x/guide/… | |
| Jan 29, 2011 at 23:10 | history | answered | time4tea | CC BY-SA 2.5 |