Timeline for Wrapping Business Logic In Extension Methods For POCOs
Current License: CC BY-SA 4.0
11 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Mar 28, 2023 at 12:54 | comment | added | Stevenfowler16 | That abstraction was the second way I thought about doing this but seemed like a lot for the one method I have added to the IEnumerable<POCO> type with the extension. | |
| Mar 24, 2023 at 13:58 | comment | added | Greg Burghardt | @Stevenfowler16: the third point in this answer, and Ewan's last comment are the drawbacks to this design. This thing is just hanging out by itself with no other purpose than to contain a method that operates on a collection. You might be missing an abstraction: PocoCollection which could define the property or method you want, and internally contains an IEnumerable<POCO> or List<POCO>, depending on whether or not you need add/remove functionality. This new PocoCollection could implement IEnumerable<POCO> and you can use that object in a foreach loop. | |
| Mar 23, 2023 at 19:32 | comment | added | Ewan | I would say, look at the bigger picture. What happens when you have more than one way to select the right poco? what happens when this function is reused all over the place and then you want to change it for one particular edge case? You can define stand alone functions all over the place if you like, but you lose the structure of OOP | |
| Mar 23, 2023 at 15:44 | comment | added | Stevenfowler16 | I also thought about adding the method to the POCO itself but that to me violates what I think a POCO should be which is just a pass through from the Data layer out we specifically call the class this is operating on a Data Transfer Object. The private method on a service class is the second way I thought about doing this. This function returns a value and then a lot of other classes will use that value to do a bunch of other things or including display, other logic etc. But then you are injecting a whole other class(potentially) to get this value out of a list which seemed like overkill. | |
| Mar 23, 2023 at 15:39 | comment | added | Stevenfowler16 | For 3. It does feel isolated or orphaned. It only ever operates on itself so it shouldn't need to be grouped up with anything else. I think I need to read a bit more on the reach of extension methods to get the point fully here. Since this is internal in a solution I should always be able to see the references. | |
| Mar 23, 2023 at 15:34 | comment | added | Stevenfowler16 | 1. Pure function and writing the unit tests was very easy. I'm trying to get away from mocking if I can as I find it's probably an indicator of a deeper problem for the level our code is at. 2. Same namespace as the poco and file is right next to the poco so kept it clean on finding them | |
| Mar 23, 2023 at 15:00 | comment | added | Ewan | I guess the question is do you know the call doesn't have side effects. If its just some pure function obvs its going to be fine, but if its some random library extension method? Same with the namespaces, sure if its all your code then you aren't going to worry, but If you are publishing services.AddWebAuthentication(config) ? | |
| Mar 23, 2023 at 14:53 | comment | added | Greg Burghardt | Mocking is not a requirement for "strict" unit testing. A "unit" of behavior is not a well-defined term, but typically you mock behavior that modifies or reads from external state. If the logic is simple and idempotent, why complicate your test with a mock? And I wouldn't worry about name collisions for domain-specific extension methods. Sure it is a risk, but it is a judgement call whether or not a naming collision is likely. | |
| Mar 23, 2023 at 14:23 | comment | added | Ewan | #1 if you are being strict your unit test wants to call a mocked version, which the static doesn't allow. #2 if you use the same namespace you are going to collide with other extension methods | |
| Mar 23, 2023 at 14:02 | comment | added | Greg Burghardt | Regarding #1, it depends on the static method. If the method is idempotent, then yes, you can write unit tests for things that call the static method. Regarding #2: it depends. If the extension methods are in the same namespace as the type it extends, then they are just as easy to find. The OP's use case is a little complicated because the proposed method extends List<T>, so you have two types requiring using statements before you can discover the method. But #3 is spot on. | |
| Mar 23, 2023 at 13:33 | history | answered | Ewan | CC BY-SA 4.0 |