eShopOnContainers
eShopOnContainers copied to clipboard
dotnet-architecture
Does probably throwing Exceptions here for business rules cause performance issue ?
Hi, I am working and reading the eShopOnContainer project and seems fantastic.
You handled business rules in some domains like here to throw an exception which is caught by HttpGlobalExceptionFilter and return its message to the caller. My question is according to here is it possible this cause the performance issue?
Maybe I missed something but this really is my concern about throwing an exception in a domain to handle business rules.
Many thanks in advance for your consideration and time
Before anyone worries about performance, that disaster of a class needs to be cleaned up. Is static code analysis even turned on? I'm seeing many violations just on causal inspection.
For example, there is a SetX method for setting property X. Why not just make X writable? And then since it's simple, change it into an auto-implemented property.
Whomever is in charge of this mess needs to go back and read the Framework Design Guidelines.
@Grauenwolf Thanks for your comment. I think there are lots of respectable valuable expert people here which worked on this project and we can not criticize them like this. :) Come back to your question if you mean somewhere like this its because in DDD we are not allowed to change properties value directly from outside of the class scope. instead, we should create some public methods to do it and keep properties private. it is the correct way to implement the Domain concepts in Entities and Aggregations.
DDD does not say that you "are not allowed to change properties value directly from outside of the class scope".
A property setter is literally a method. It's a special kind of method, with certain aspects that show up in reflection, but it's still a method.
Whomever wrote this code is nether an expert in DDD nor in .NET API design. We should not blindly defer to their mistakes when we have the Framework Design Guidelines and matching code analysis tools to tell us they are wrong.
Thinking about this again, novices often confuse the common English word "property" as in "some aspect of a thing" with the .NET concept Property.
The book on DDD was written in 2003, a time when only VB and C# had the concept of property methods.
I can certainly see the people who created this project making that mistake. But again, I wouldn't call them experts.
@Grauenwolf I love your passion on this. Sounds like you would be the perfect person to create a pull request correcting the short comings of this class.
Considering the issue has had no activity for many months, closing it as of now.
