Mendz.Data.* And Your Team
Mendz.Data is designed with the team in mind. Different developers have different styles. A good team respects each member developer's style. However, a team working on the same project should also mean that all developers agree on many things. At the very least, code completeness, consistency and quality should be predictably maintainable and measureable.
For example, should a team decide that they want to use "repository pattern" in their applications, they should first and foremost agree on what "repository pattern" to use. Now that statement is weird. If the repository pattern is a pattern, isn't there only one way to do it?
The truth is, patterns can be interpreted and implemented differently. Whichever interpretation and implementation can be correct, for as long as they cover the full essence and scope of the pattern, by its definition and for its intent. Strictly, the repository pattern is complicated. For example, in Microsoft's Entity Framework, DbContext internally implements the Unit of Work and Repository patterns. If you are familiar with the Entity Framework, you can imagine how difficult it can be to match its feat. As with most ORM's, the abstraction level is top notch. For teams developing enterprise applications, they are not necessarily in the business of developing abstractions. In the real world, the main goal is to deliver on business requirements.
Thus, with regards to choosing which "repository pattern" to adopt, it can mean choosing which close enough interpretation and implementation of the repository pattern the team can use. In this sense, the repository pattern has been reduced to mean a way to separate the data access codes from the application code. There are many "repository pattern" like this available in print and online.
Although EF internally implements the repository pattern, EF-based codes are generally considered as modern data accessing codes. In a sense, the use of LINQ is the criteria specification part of EF's UoW-Repository design. However, as it turns out, LINQ redefined what data accessing code can look like. For ASP.Net MVC applications for example, it's a question of whether data accessing codes should be in the controller, or hidden instead in the repository.
So let's say for example that the team decides to use EF and that they want to separate/hide their EF-based codes in a "repository pattern" of their own. The team can design it from scratch. They can pick up from samples in print and online. Or, they can use Mendz.Data, which is made to provide the tools and guidance for developing contexts and repositories, while not necessarily distracting the team from focusing on the business requirements.
Mendz.Data can help the team to quickly create contexts and repositories that are flexible, scalable and capable of growing as the application itself grows. Objects derived from Mendz.Data interfaces and base classes can achieve consistent coding patterns and quality. Mendz.Data.Repository(.Async) offers ready-to-use "templates" for implementing CRUDS operations. As a result, application codes can also achieve consistent coding patterns and quality.
Compare the samples provided in Mendz.Data Wiki and in Mendz.Data.SqlServer Wiki. Do you see what I'm talking about? Mendz.Data jumpstarts how the team can establish consistent coding patterns and quality in their work. Regardless if the team would use one or more types of contexts (EF/ORM, Dapper/ADO.Net-based or vendor specific like MongoDB) in their applications, Mendz.Data can be used to maintain consistency with all of them.
For example, should a team decide that they want to use "repository pattern" in their applications, they should first and foremost agree on what "repository pattern" to use. Now that statement is weird. If the repository pattern is a pattern, isn't there only one way to do it?
The truth is, patterns can be interpreted and implemented differently. Whichever interpretation and implementation can be correct, for as long as they cover the full essence and scope of the pattern, by its definition and for its intent. Strictly, the repository pattern is complicated. For example, in Microsoft's Entity Framework, DbContext internally implements the Unit of Work and Repository patterns. If you are familiar with the Entity Framework, you can imagine how difficult it can be to match its feat. As with most ORM's, the abstraction level is top notch. For teams developing enterprise applications, they are not necessarily in the business of developing abstractions. In the real world, the main goal is to deliver on business requirements.
Thus, with regards to choosing which "repository pattern" to adopt, it can mean choosing which close enough interpretation and implementation of the repository pattern the team can use. In this sense, the repository pattern has been reduced to mean a way to separate the data access codes from the application code. There are many "repository pattern" like this available in print and online.
Although EF internally implements the repository pattern, EF-based codes are generally considered as modern data accessing codes. In a sense, the use of LINQ is the criteria specification part of EF's UoW-Repository design. However, as it turns out, LINQ redefined what data accessing code can look like. For ASP.Net MVC applications for example, it's a question of whether data accessing codes should be in the controller, or hidden instead in the repository.
So let's say for example that the team decides to use EF and that they want to separate/hide their EF-based codes in a "repository pattern" of their own. The team can design it from scratch. They can pick up from samples in print and online. Or, they can use Mendz.Data, which is made to provide the tools and guidance for developing contexts and repositories, while not necessarily distracting the team from focusing on the business requirements.
Mendz.Data can help the team to quickly create contexts and repositories that are flexible, scalable and capable of growing as the application itself grows. Objects derived from Mendz.Data interfaces and base classes can achieve consistent coding patterns and quality. Mendz.Data.Repository(.Async) offers ready-to-use "templates" for implementing CRUDS operations. As a result, application codes can also achieve consistent coding patterns and quality.
Compare the samples provided in Mendz.Data Wiki and in Mendz.Data.SqlServer Wiki. Do you see what I'm talking about? Mendz.Data jumpstarts how the team can establish consistent coding patterns and quality in their work. Regardless if the team would use one or more types of contexts (EF/ORM, Dapper/ADO.Net-based or vendor specific like MongoDB) in their applications, Mendz.Data can be used to maintain consistency with all of them.
Comments
Post a Comment