Timeline for C# coding style, functional approach
Current License: CC BY-SA 4.0
15 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Oct 26, 2022 at 12:51 | answer | added | candied_orange | timeline score: 2 | |
| Oct 26, 2022 at 8:23 | answer | added | Robert Bräutigam | timeline score: 0 | |
| Oct 26, 2022 at 7:57 | comment | added | John Wu | OP, can you elaborate on "functional approach" and what that means to you in this context? Would love to see an example of how the helpers make the UseCase look cleaner. | |
| Oct 26, 2022 at 6:47 | history | reopened |
candied_orange Doc Brown Bart van Ingen Schenau |
||
| Oct 25, 2022 at 14:38 | comment | added | candied_orange | This question discussed on meta | |
| Oct 25, 2022 at 14:16 | comment | added | Doc Brown | Let me reiterate my point with different words to make it clearer: I think there is nothing wrong in starting a small program with only few layers and an anemic data model, as shown in the question. But when your program starts to grow, you will find several occasions to refactor (for example, methods which can serve multiple use-cases might be moved into your data objects). It is not the decision you make today on your code structure which will bite back on you, but the lack of adapting it constantly when your program grows. | |
| Oct 25, 2022 at 13:16 | comment | added | Cowborg | Ok, that answer says absolutely nothing, I understand why this question got closed down. | |
| Oct 25, 2022 at 13:06 | comment | added | Ben Cottrell | I think the simple answer to this not to worry about what problems the code might face in the future, because that depends on assumptions about things that might happen, not things which are certain. Code is supposed to change as its requirements change yet trying to pre-empt change is futile. The best you can do is code for requirements you're certain about "today", keep things simple and invest a lot more effort in automated behavioural testing (tests which test behaviour, not code structure) so that it's much easier for future developers to rewrite the code later. | |
| Oct 25, 2022 at 12:59 | review | Reopen votes | |||
| Oct 26, 2022 at 6:51 | |||||
| Oct 25, 2022 at 12:58 | history | closed |
Doc Brown Greg Burghardt Ben Cottrell |
Opinion-based | |
| Oct 25, 2022 at 12:53 | comment | added | Cowborg | I familiar with DDD and since its so popular its hard discussing against it. One problem I have against it, is the domain object that gets large and multi purposed since they have to handle every context, and then comes the division into BC, which is too much of a moving target. BUT this thread was not to discuss DDD, since there are millions of articles and threads about it. It was to discuss this approach and similar ones | |
| Oct 25, 2022 at 12:46 | review | Close votes | |||
| S Oct 25, 2022 at 13:00 | |||||
| Oct 25, 2022 at 12:29 | comment | added | Doc Brown | For small to medium sized applications, this will be sufficient. But the larger your program will get, the more structure it will require. There are whole books written about this topic (like "Domain Driven Design" by Eric Evans), and it is also a very opinionated topic, IMHO too opinionated for the Q&A format of this site. | |
| S Oct 25, 2022 at 12:12 | review | First questions | |||
| S Oct 25, 2022 at 13:00 | |||||
| S Oct 25, 2022 at 12:12 | history | asked | Cowborg | CC BY-SA 4.0 |