![]() ![]() A better approach should be to isolate the code that performs logging in the Repository class to another class. Also, there might be a possibility that over a period of time you would have to log the errors to many different log targets, i.e., file, database, event viewer, etc. In all possibilities logging errors is not what a repository class is supposed to do. I prefer using repositories primarily to isolate business logic code from the data access logic. A Repository class is not supposed to log errors as it is not the purpose of it. This breaks SRP since the new Repository class now performs two different types of operations, i.e., it now handles two responsibilities - it stores data to the underlying data store and also logs the errors (if any) to a text file. OK, so what's the problem in this approach? Refer to the modified Repository class. ![]() Here's how the modified Repository class would look like. Now suppose you need to write some error handling code in your Repository class. Public class Repository : IRepository where T : class where D : DbContext, new() The Repository class implements the IRepository interface and implements the Create and Save methods as shown next. Public interface IRepository where T : class Consider the following interface that represents the base interface for an implementation of a generic repository. Now, what if you have two methods in your class those have different responsibilities? Does this violate SRP? In my opinion this wouldn't violate SRP - you should understand that SRP implies that classes should have a single responsibility at the correct level of abstraction. As an example, you can have a class Repository that performs operations on the database - you can use it to persist and retrieve data to and from the underlying database. When you design your classes, the name of the class should denote its responsibility. To isolate the responsibilities you would need to define a class or an interface for each responsibility. If there are multiple reasons for a class to change, it breaks SRP. When a class has more than one responsibility, it has more than one reason for change. Responsibility in the context of SRP can be defined as a reason for change. Albeit being the simplest of all the SOLID principles, the SRP is one of the most difficult to be implemented the right way. The basic idea behind SRP is that two or more separate responsibilities should be separated in distinct classes or modules - it is a bad design approach to couple different responsibilities in the same class if such responsibilities might change over time. The classes and interfaces in an application often become bloated when they have to perform too many different responsibilities. Increased readability, extensibility and maintenance.The same book was later republished as a C# version as "Agile Software Development Principles, Patterns and Practices in C#". Martin in his book "Agile Software Development Principles, Patterns and Practices". ![]() When a class has more than one responsibility, such responsibilities are coupled and this coupling leads to designs that are fragile and can break over time. If there are two reasons for a class to change, the functionality should be split into two classes with each class handling one responsibility. The Single Responsibility Principle states that a class should have one and only one reason for change, i.e., a subsystem, module, class or a function shouldn't have more than one reason for change. The five SOLID principles are Single Responsibility (SRP), Open/Close, Liskov's Substitution, Interface Segregation, and Dependency Inversion. In this post, I'll present a discussion on the Single Responsibility Principle with code examples to illustrate the concepts. SOLID is a popular acronym used to refer to a set of five principles of software architecture.
0 Comments
Leave a Reply. |
Details
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |