I am programming library collecting some data. It will be able to switch its repositories to change data destination (database/files). I have more entities to store, such as cities, streets etc. My plan is to publish an interface, which will bee needed to implement, to create custom repository for custom data store.
I have seen, each repository takes care of one entity. But in such case, there should be more interfaces - for each repository. Is it OK (in repository design pattern mean) to create single repository accepting all needed entities and publish just one interface? With more interfaces there is possibility to forget to implement some and create inconsistent data api.
Is there better way how to solve this?
Each repository can return different entities. But if you group everything together in one interface, it would be really hard for other developers to read and maintain. In my development project, we try to make sure the each repository return related entities. Hope this helps.
I usually go for hybrid in the sense that, I have a base repository and extending repositories which would need custom implementation.
ie:
public class BaseRepo<T> : IRepo<T> where T: TEntity
{
// common functionality for all repos
// such as find, add, remove etc.
}
However, most of the time you will need more than CRUD, especially for selects.
It is a terrible idea to pass around expression trees which kills you testability and maintainability.
Moreover, You wont be able to use Dependency Injection if you have a single repo, which you is certainly doable. But highly discouraged.
You need to separate the responsibilities of repositories. Follow SOLID principles. and create a good API.
I suggest to create a GeographicRepository that would contain references to multiple datasources, and accept featureType as parameter.
A possible way to use this would be (pseudocode):
var rep = new GeoRepository();
var citylist = rep.getEntities(featureType='city');
// or instead:
var citylist = rep.getCities()
EDIT: a suggestion based on the central repo vs. fragmented repo would be to have a RepositoryFaçade to be an aggregator of individual (and individually testable) repositories:
var centralRepo = new GeoRepository();
centralRepo.connectRepository(new GoogleCityRepo());
centralRepo.connectRepository(new YahooVillagesRepo());
centralRepo.connectRepository(new USGSDatabaseRepo('C:\usgs_usa_counties.db'));
Of course the way to create/declare "connections" would vary: hardcoded in the constructor, depending on service availabilty, explicit (as shown above), whatever. Also, that would allow for individual testing by writing a harness façade that would call only a single repo.
Hope this helps!
Short Answer: Yes, you can use a single repository for all operations.
Long Answer: When i first started using repositories, i thought the only approach was to use a repository for each entity then i found this excellent article "Query Objects with the Repository Pattern" where the author discussed whether to use a single repository per aggregate root or a repository for each entity, or just a single repository for the whole thing. He concluded with a very tempting opinion to use a single repository for everything with the combination of query object pattern for querying the data source, i really liked the end result and you might.
Related
Recently, I am refactoring my DDD project. When I look at my Repository Layer. I found it return IQueryable< T> in my repository. I am puzzled and should I return IQueryable< T> from a repository in my DDD project in Repository Layer? I usually return IQueryable type in my Repository design. But today I found a opposite idea from this article
I can't figure it out!
If you return IQueryable you permit domain knowledge leaking from Domain layer to the consumer layers. It increases the risk that your Domain objects will become anemic and all behavior will move to other layers.
Although it seams very handy to return a IQueryable and you think that your code becomes simpler, that is just an illusion; when the project will grow that IQueryable will transform your code into a big ball of mud, with domain code scattered every where. You won't be able to optimize your repository or to change one persistence with another (i.e. from sql to nosql).
You probably shouldn't do that.
The repository's job is not only to abstract away persistence details, but also to provide an explicit query contract defining those that are needed to process commands1 in your domain.
If you feel the need to further filter/transform what's returned from your repository then you most likely failed to capture an explicit query that should be part of the repository's contract.
Having such contract lets the querying clients express their intent and allows for easier optimizations.
1. Nowadays, it's quite common to apply some CQRS principles and by-bass the domain model entirely for queries. Given this scenario, the only queries that would go through the repository are the ones needed to process commands. You are however not forced in any way to use this approach so your repository could fulfill reporting queries as well if you wish.
I am trying to use repositories in my MVC program designs and I have run up against a problem on how to best structure them.
as an example, say I have an object USers and I have a UserRepository which has functions like getUser(int id), saveUser(Dal.User model) etc...
So If in my controller I have EditUser and I want to display a view that will have a user details input form. so I can do something like this:
User user = _userRepository.getUserDetails(userId);
The benefit being that my controller just deals with processing HTTP requests, and business logic is moved to repositories, making testing etc easier
So, say I want to display a drop down list of possible roles this user could have in my system, ie client, admin, staff etc
is it ok to have a function in the _userRepository called getPossibleUserRoles() or should I have a seperate _roleRepository with a function getRoles() ?
IS it a bad idea to inject a repository for every entity you encounter into your controller? or is it a bad idea to mix entities inside your repositories, making them cluttered.
I realise I have presented a very simplistic scenario, but obviously as systems grow in complexity you are potentially talking of 10s of repositories needing to be instantiated in a controller for every page call. and also possibly instantiating repositories that are not being used in current controller methods simply to have them available to other controller methods.
Any advice on how best to structure a project using repositories appreciated
is it ok to have a function in the _userRepository called
getPossibleUserRoles() or should I have a seperate _roleRepository
with a function getRoles() ?
Let's say you have some controllers call:
_userRepository.getUserDetails(userId);
but they never call:
_userRepository.getPossibleUserRoles(userId);
Then you are forcing your controllers to depend on methods they do not use.
Sot it's not just ok, you should split this.
But if getUserDetails and getPossibleUserRoles are chosive (sharing same entity, sharing same business logic etc..).
You can split this without changing implemantation of userrepository beside of creating new class for Roles.
public class UserRepsitory : IUserRoles, IUserRepository
{
}
I realise I have presented a very simplistic scenario, but obviously
as systems grow in complexity you are potentially talking of 10s of
repositories needing to be instantiated in a controller
If a constructor gets too many parameters, there is high posibility SRP violation. Mark Seemann shows how to solve this problem in here.
In a short way: While you are creating a behaviour, if you use always 2 or more than repositories together. Then, these repositories are very close. So you can create a service and orchestrate them in this service. After that, you can use this service as a paremeter beside of using 2 or more repositories in your controller constructor.
is it ok to have a function in the _userRepository called getPossibleUserRoles() or should I have a seperate _roleRepository with a function getRoles() ?
Both solutions are acceptable but consider how you're going to control the proliferation of repositories and methods on those repositories. IMHO, the typical repository usage scenario tends to end-up with too many repositories with too many methods on each. DDD advocates a repository per aggregate root. This is a good rule of thumb... if you're following DDD principles.
IS it a bad idea to inject a repository for every entity you encounter into your controller? or is it a bad idea to mix entities inside your repositories, making them cluttered.
Inject volatile dependencies, so yes, inject a repository for every entity your controller needs. However, once you start injecting more than four dependencies, chances are you've missed an abstraction somewhere in your design. Some solve this problem with RepositoryFactory but this, arguably, introduces the problem of opaque dependencies and, IMHO, fails to convey the class's real dependencies, reducing its usability and self-document-ability.
Take a look at using query objects rather than repositories (https://lostechies.com/jimmybogard/2012/10/08/favor-query-objects-over-repositories/, etc.) and take a look at using orchestration/mediation (http://codeopinion.com/thin-controllers-cqrs-mediatr/) in your controllers. I think you'll find a better design emerges that will help you with your design issues.
I've been working with NHibernate for quite a while and have come to realize that my architecture might be a bit...dated. This is for an NHibernate library that is living behind several apps that are related to each other.
First off, I have a DomainEntity base class with an ID and an EntityID (which is a guid that I use when I expose an item to the web or through an API, instead of the internal integer id - I think I had a reason for it at one point, but I'm not sure it's really valid now). I have a Repository base class where T inherits from DomainEntity that provides a set of generalized search methods. The inheritors of DomainEntity may also implement several interfaces that track things like created date, created by, etc., that are largely a log for the most recent changes to the object. I'm not fond of using a repository pattern for this, but it wraps the logic of setting those values when an object is saved (provided that object is saved through the repository and not saved as part of saving something else).
I would like to rid myself of the repositories. They don't make me happy and really seem like clutter these days, especially now that I'm not querying with hql and now that I can use extension methods on the Session object. But how do I hook up this sort of functionality cleanly? Let's assume for the purposes of discussion that I have something like structuremap set up and capable of returning an object that exposes context information (current user and the like), what would be a good flexible way of providing this functionality outside of the repository structure? Bonus points if this can be hooked up along with a convention-based mapping setup (I'm looking into replacing the XML files as well).
If you dislike the fact that repositories can become bloated over time then you may want to use something like Query Objects.
The basic idea is that you break down a single query into an individual object that you can then apply it to the database.
Some example implementation links here.
I've been confused by what I've been reading during my research on the repository pattern. I'm wondering if folks are (incorrectly?) using that word when they simply mean a data access layer.
Since "repository" is not found in the index of Design Patterns (GoF), I've turned to Patterns of Enterprise Application Architecture (Fowler). Fowler seems pretty clear (page 323) when he states that clients create a criteria object and pass it to the repository to get the results. It looks something like this:
public class Person
{
public List<Person> Dependents()
{
Repository repository = Registry.personRepository();
Criteria criteria = new Criteria();
criteria.equal(Person.BENEFACTOR, this);
return repository.matching(criteria);
}
}
Is the criteria object what makes the repository a repository? If not, what does? If abstracting the persistence mechanism (and therefore constructing queries) is the goal, in what way does the repository differ from a simpe DAL/ORM call like this:
public class PersonLogic
{
public List<Person> GetDependents()
{
IPersonData personData = DependencyContainer.Resolve<IPersonData>();
return personData.GetDependents();
}
}
To me, the difference looks like this:
* With the repository pattern, the client constructs different criteria objects and calls the Matching() method on it.
* With the simple DAL, clients just call different methods based on what they want.
Is there more to it than this? Are programmers mistakenly using the term "repository" when they really mean DAL?
EDIT
David Osborne sent this link to Persistence Patterns. It states:
Basically, the Repository pattern just means putting a façade over
your persistence system so that you can shield the rest of your
application code from having to know how persistence works.
That's really what a data access layer is. It really appears to me that a repository and a DAL are the same thing, and maybe a "true" repository uses the criteria object.
Take a look at the "Using the IQueryable interface" section and beyond at Extending and Enhancing the Orders and Registrations Bounded Context. It provides an insightful and balanced discussion of DAO/Repository implementations.
As subsequently highlighted by Bob Horn, the Persistence Patterns articles summarises that:
Basically, the Repository pattern just means putting a façade over your persistence system so that you can shield the rest of your application code from having to know how persistence works.
In general I agree with author's statements, but I'd like to add some details
Difference between Repository and DAL/ORM that first not only abstracts the persistence mechanism, but also provides collection-like interface for accessing domain objects … and isolates domain objects from details of the database access code:
Differences
For external layers, such as Business Logic:
Helps to avoid leaky abstraction. External layers depend on abstraction of Repository, rather than a specific implementation of DAL/ORM. Thus you could avoid all infrastructure and logical dependencies while working with Repository.
operates with domain objects, rather then a instances of POJO/POCO/DTO
CRUD operations applied to collection-like interface provided by Repository, rather then specific DAL/ORM methods. For example .net: working with collection that implements IEnumerable, rather then entity-framework context or nhibernate session
Similarities
Repository contains DAL/ORM underneath and serves same purpose
I'm currently trying out a few different ways of implementing repositories in the project I'm working on, and currently have a single repository with generic methods on it something like this:
public interface IRepository
{
T GetSingle<T>(IQueryBase<T> query) where T : BaseEntity;
IQueryable<T> GetList<T>(IQueryBase<T> query) where T : BaseEntity;
T Get<T>(int id) where T : BaseEntity;
int Save<T>(T entity) where T : BaseEntity;
void DeleteSingle<T>(IQueryBase<T> query) where T : BaseEntity;
void DeleteList<T>(IQueryBase<T> query) where T : BaseEntity;
}
That way I can just inject a single repository into a class and use it to get whatever I need.
(by the way, I'm using Fluent NHibernate as my ORM, with a session-per-web-request pattern, and injecting my repository using Structuremap)
This seems to work for me - the methods I've defined on this repository do everything I need. But in all my web searching, I haven't found other people using this approach, which makes me think I'm missing something ... Is this going to cause me problems as I grow my application?
I read a lot of people talking about having a repository per root entity - but if I identify root entities with some interface and restrict the generic methods to only allow classes implementing that interface, then aren't I achieving the same thing?
thanks in advance for any offerings.
I'm currently using a mix of both generic repositories (IRepository<T>) and custom (ICustomRepository). I do not expose IQueryable or IQueryOver from my repositories though.
Also I am only using my repositories as a query interface. I do all of my saving, updating, deleting through the Session (unit of work) object that I'm injecting into my repository. This allows me to do transactions across different repositories.
I've found that I definitely cannot do everything from a generic repository but they are definitely useful in a number of cases.
To answer your question though I do not think it's a bad idea to have a single generic repository if you can get by with it. In my implementation this would not work but if it works for you then that's great. I think it comes down to what works best for you. I don't think you will ever find a solution out there that works perfectly for your situation. I've found hybrid solutions work best for me.
I've done something similar in my projects. One drawback is that you'll have to be careful you don't create a select n+1 bug. I got around it by passing a separate list of properties to eagerly fetch.
The main argument you'll hear against wrapping your ORM like this is that it's a leaky abstraction. You'll still have to code around some the "gotchas" like select n+1 and you don't get to take full advantage of things like NH's caching support (at least not without extra code).
Here's a good thread on the pros and cons of this approach on Ayende's blog. He's more or less opposed to the pattern, but there are a few counter arguments too.
I've implemented such kind of repository for NHibernate. You can see example here.
In that implementation you are able to do eager loading and fetching. The pitfall is that with NH you will often need to be able to use QueryOver or Criteria API to access data (unfortunately LINQ provider is still far from being perfect). And with such an abstraction it could be a problem leading to leaky abstraction.
I have actually moved away from repository pattern and creating a unit of work interfaces - I find it limiting.
Unless you anticipate a change in the datastore i.e. going from DB to textfile or XML - which has never been the case for me, you are best off using ISession. You are trying to abstract your data access and this is exactly what NHibernate does. Using repository limits really cool features like Fetch(), FetchMany() futures etc. ISession is your unit of work.
Embrace NHibernate and use the ISession directly!
I've used this approach successfully on a few projects. It gets burdensome passing in many IRepository<T> to my Service layers for each BaseEntity, but it works. One thing I would change is put the where T : on the interface rather than the methods
public interface IRepository<T> where T : BaseEntity