3 Replies - 688 Views - Last Post: 17 July 2017 - 11:45 PM

#1 garbus   User is offline

  • New D.I.C Head

Reputation: 0
  • View blog
  • Posts: 22
  • Joined: 18-June 17

Does the .NET framework violate S.O.L.I.D?

Posted 17 July 2017 - 09:54 AM

I see some classes in the .net framework that support reading and writing, saving and loading, classes whose main responsibility are not those, for instance the Stream classes and the XML Dom/XLinq classes.

Since the .net framework apparently violates the Single Responsibility Principle, should I create entity classes with methods for database storage and retrieval? In other words, should my custom entity classes (not using entity framework), be responsible for accessing a database, or should I create a separate class for that?

Is This A Good Question/Topic? 0
  • +

Replies To: Does the .NET framework violate S.O.L.I.D?

#2 modi123_1   User is online

  • Suitor #2
  • member icon

Reputation: 14044
  • View blog
  • Posts: 56,199
  • Joined: 12-June 08

Re: Does the .NET framework violate S.O.L.I.D?

Posted 17 July 2017 - 10:01 AM

I think an umbrella namespace is fine with it.

Is your db interaction going to be sufficiently complex, or muddled, to require it being popped out on their own?
Was This Post Helpful? 1
  • +
  • -

#3 Skydiver   User is online

  • Code herder
  • member icon

Reputation: 6166
  • View blog
  • Posts: 21,264
  • Joined: 05-May 12

Re: Does the .NET framework violate S.O.L.I.D?

Posted 17 July 2017 - 05:07 PM

The lower level objects do follow the SRP. They wrap the low level handle or connection that you need to communicate with the OS or a network/web resource to provide a level of abstraction for an OS object/concept.

If you go up one level, you have things like the stream writers and stream reader which do follow the SRP where their focus is more task related, rather than abstraction related.
Was This Post Helpful? 2
  • +
  • -

#4 cfoley   User is offline

  • Cabbage
  • member icon

Reputation: 2388
  • View blog
  • Posts: 5,013
  • Joined: 11-December 07

Re: Does the .NET framework violate S.O.L.I.D?

Posted 17 July 2017 - 11:45 PM

I would say both are "abstraction-related". Just that they are at different levels of abstraction.

For me SOLID provides a framework to think about my code rather than just a set of rules to follow. In the OO world people tend to apply it to classes but it really applies to any unit of code: functions, lines, layers. Whatever.

Here are the sorts of questions I ask:

S: What responsibility does this unit of code have, expressed at an appropriate granularity for that abstraction. Is there more than one responsibility? Conversely, given a particular change I want to make, is the responsibility in one place or is it spread around?

O: In what ways can I expend this without modifying it? Injecting code, adding parameters to the end of a list, overloading, wrapping, extending, adding lines of code to the end of a function or file.

L: For me, this one is more thinking about whether I should be allowing for things to be substituted, rather than an instruction to give everything an interface.

I: This is a metric that I use to guide when I split things up, not a hard and fast rule.

D: Again, this one is about choosing your code injection carefully.

So, to go back to your question, should your entity classes contain database code?

S: These seem like different responsibilities to me. Therefore, different parts of your code should be responsible for them. The database code should certainly have its own set of methods. If it is complex enough, its class or set of classes. If you think about it, this is the same as modi123_1's answer.

O: How are you going to modify these in the future? What changes are likely. What design will make these changes easier?

L: Do you think you will need to use a different storage mechanism? What about on different devices? Or for testing?

I: This is maybe the most interesting one. Should methods that perform calculations based on entities have access to the database functions? Should methods that load and save data have access to the methods that manipulate the entity? Splitting the class up is one way to achieve that separation but so is implementing multiple interfaces. Then each part of the program can access the class via its own interface.

D: Is there a behaviour of the class that you want to be able to change? Maybe you want to wrap a logger around the database calls or you want to create an entity without giving it a connection string.

I think answers to these sorts of questions should drive your design, and the answers will vary depending on what you want to achieve.
Was This Post Helpful? 1
  • +
  • -

Page 1 of 1