The Beauty of Mendz.Data.Repository(.Async)
The truth is, you can use the Mendz.Data.Repository and Mendz.Data.Repository.Async CRUDS interfaces in your own custom repository implementations. There is nothing in this namespace that requires you to use them only in purely Mendz.Data-based contexts and repositories.
Mendz.Data is designed to provide the APIs that would let you quickly create contexts and repositories that simply work well together. It proposes the concept of semi-self-initializing data contexts, which help shield the application from the intricacies of the data access layer, including "knowing" about any specific data contexts. When used with Mendz-Data-aware repositories, the application is only required to reference Mendz.Data, and the models and repositories libraries.
The Mendz.Data.Repository (and Mendz.Data.Repository.Async) namespaces though are unique. The classes and types defined in these namespaces can be used independently of the classes and types in Mendz.Data and Mendz.Data.Common namespaces. Using only Mendz.Data.Repository (or Mendz.Data.Repository.Async), you can easily combine your own repository implementation with the Mendz.Data.Repository(.Async)'s CRUDS interfaces.
For the most part, repository base classes manage the context lifetimes. Different developers may have different styles of achieving this. Mendz.Data-based repositories are designed to have a parameter-less constructor, relying on the assumption that the context is semi-self-initializing. Some repositories may have explicit requirement to pass the context during construction. Still some, may use dependency injection to pass in the context. Beyond initialization, repositories are pretty much the same: they expose CRUDS methods.
Many "repository pattern" implementations put all CRUDS methods in a single interface. Mendz.Data.Repository(.Async) proposes otherwise. Instead of assuming that the repository will always need to scaffold all CRUDS methods for a model, Mendz.Data.Repository(.Async) assumes that you may need to implement only some. This is based on the knowledge that different models may have different requirements. Although many models may require the full CRUDS set, there are models that don't. An example is a model that represents immutable data, which can be created, read, deleted or searched, but can't be updated. Another example is a readonly model that can be read or searched, but can't be created, updated or deleted.
Now let's say you agree with this, instead of coming up with CRUDS interfaces from scratch, you can instead use Mendz.Data's Mendz.Data.Repository(.Async) CRUDS interfaces. You can have a minimal repository interface or base class of your own, for example. In repository implementation projects, you just add a reference Mendz.Data and use its Mendz.Data.Repository(.Async) CRUDS interfaces to put in the CRUDS methods that your model needs.
The Mendz.Data.Repository(.Async) CRUDS interfaces are intentionally non-imposing. They are meant to provide guidance by helping you establish coding patterns. For example, if you have a new requirement that expands on the basic Search, like SearchByCustomer, you can just copy the original Search signature to a new SearchByCustomer method and continue from there. This allows your repositories to grow with your application's needs. As in this example, it allows you to have Search and as many variations of SearchBy* in the same repository, all following more or less the same coding pattern.
Jump start your repository development with Mendz.Data. Get it from NuGet: https://www.nuget.org/packages/Mendz.Data/ and start delivering results quick and easy, not just for you, but also for your team.
Have fun!
Mendz.Data is designed to provide the APIs that would let you quickly create contexts and repositories that simply work well together. It proposes the concept of semi-self-initializing data contexts, which help shield the application from the intricacies of the data access layer, including "knowing" about any specific data contexts. When used with Mendz-Data-aware repositories, the application is only required to reference Mendz.Data, and the models and repositories libraries.
The Mendz.Data.Repository (and Mendz.Data.Repository.Async) namespaces though are unique. The classes and types defined in these namespaces can be used independently of the classes and types in Mendz.Data and Mendz.Data.Common namespaces. Using only Mendz.Data.Repository (or Mendz.Data.Repository.Async), you can easily combine your own repository implementation with the Mendz.Data.Repository(.Async)'s CRUDS interfaces.
For the most part, repository base classes manage the context lifetimes. Different developers may have different styles of achieving this. Mendz.Data-based repositories are designed to have a parameter-less constructor, relying on the assumption that the context is semi-self-initializing. Some repositories may have explicit requirement to pass the context during construction. Still some, may use dependency injection to pass in the context. Beyond initialization, repositories are pretty much the same: they expose CRUDS methods.
Many "repository pattern" implementations put all CRUDS methods in a single interface. Mendz.Data.Repository(.Async) proposes otherwise. Instead of assuming that the repository will always need to scaffold all CRUDS methods for a model, Mendz.Data.Repository(.Async) assumes that you may need to implement only some. This is based on the knowledge that different models may have different requirements. Although many models may require the full CRUDS set, there are models that don't. An example is a model that represents immutable data, which can be created, read, deleted or searched, but can't be updated. Another example is a readonly model that can be read or searched, but can't be created, updated or deleted.
Now let's say you agree with this, instead of coming up with CRUDS interfaces from scratch, you can instead use Mendz.Data's Mendz.Data.Repository(.Async) CRUDS interfaces. You can have a minimal repository interface or base class of your own, for example. In repository implementation projects, you just add a reference Mendz.Data and use its Mendz.Data.Repository(.Async) CRUDS interfaces to put in the CRUDS methods that your model needs.
The Mendz.Data.Repository(.Async) CRUDS interfaces are intentionally non-imposing. They are meant to provide guidance by helping you establish coding patterns. For example, if you have a new requirement that expands on the basic Search, like SearchByCustomer, you can just copy the original Search signature to a new SearchByCustomer method and continue from there. This allows your repositories to grow with your application's needs. As in this example, it allows you to have Search and as many variations of SearchBy* in the same repository, all following more or less the same coding pattern.
Jump start your repository development with Mendz.Data. Get it from NuGet: https://www.nuget.org/packages/Mendz.Data/ and start delivering results quick and easy, not just for you, but also for your team.
Have fun!
Comments
Post a Comment