repository-pattern | 易学教程

Repository Pattern - POCOs or IQueryable?

阅读更多关于 Repository Pattern - POCOs or IQueryable?

问题 I'm new to the Repository Pattern and after doing a lot of reading on the web I have a rough understanding of what is going on, but there seems to be a conflict of ideas. One is what the IRepository should return. I would like to deal in ONLY Pocos so I would have an IRepository implementation for every aggregate root, like so: public class OrangeRepository: IOrangeRepository { public Orange GetOrange(IOrangeCriteria criteria); } where IOrangeCriteria takes a number of arguments specific to

How do I handle table relationships with the repository pattern?

阅读更多关于 How do I handle table relationships with the repository pattern?

问题 I'm implementing the repository pattern as part of an ASP.NET MVC site. Most examples I've seen of repositories are fairly simple. For example here's a typical abstract repository interface. public interface IRepository<TEntity> { IQueryable<TEntity> All(); TEntity FindBy(int id); TEntity FindBy(Expression<Func<TEntity, bool>> expression); IQueryable<TEntity> FilterBy(Expression<Func<TEntity, bool>> expression); bool Add(TEntity entity); bool Update(TEntity entity); bool Delete(TEntity entity

Spring with Neo4j, GraphRepository<?> vs handmade interface

阅读更多关于 Spring with Neo4j, GraphRepository vs handmade interface

I found out that there is an interface called GraphRepository. I have a repository for users implementing a homemade interface that does its job, but I was wondering, shouldn't I implement GraphRepository instead ? Even if it will be quite long to implement and some methods will be useless, I think it is a standard and I already re-coded a lot of methods that are defined in this interface. So should I write "YAGNI" code or not respect the standard ? What is your advice ? you don't need to actually implement GraphRepository but extend it. the principals of Spring-Data is that all the boiler

Still lost on Repositories and Decoupling, ASP.NET MVC

阅读更多关于 Still lost on Repositories and Decoupling, ASP.NET MVC

I'm still on my eternal quest to build (and understand) modern programming convention of decoupling, IoC, DI, etc. I'm to the part where I am trying to figure out how to build a repository. I've examined the post at Database abstraction layer design - Using IRepository the right way? which was very helpful, but I've still got some problems that are just befuddling me all the way. I have my program in now 4 layers... Web (Project | ASP.NET MVC Application) - References Models.dll and Persistence.dll Models (Domain Objects) Persistence (Fluent nHibernate Mapping of Domain Objects) Utilities

Domain Driven Design (Linq to SQL) - How do you delete parts of an aggregate?

阅读更多关于 Domain Driven Design (Linq to SQL) - How do you delete parts of an aggregate?

I seem to have gotten myself into a bit of a confusion of this whole DDD\LinqToSql business. I am building a system using POCOS and linq to sql and I have repositories for the aggregate roots. So, for example if you had the classes Order->OrderLine you have a repository for Order but not OrderLine as Order is the root of the aggregate. The repository has the delete method for deleting the Order, but how do you delete OrderLines? You would have thought you had a method on Order called RemoveOrderLine which removed the line from the OrderLines collection but it also needs to delete the OrderLine

What is best practise for repository pattern - repo per table?

阅读更多关于 What is best practise for repository pattern - repo per table?

The repository pattern seems to work well when working with an initial project with several large main tables. However as the project grows it seems a little inflexible. Say you have lots of child tables that hang off the main table, do you need a repository for each table? E.g. CustomerAddress Record has following child tables: -> County -> Country -> CustomerType On the UI, 3 dropdown lists need to be displayed, but it gets a bit tedious writing a repository for each of the above tables which selects the data for the dropdowns. Is there a best practice/more efficient way of doing this? As an

Not finding .Include() method in my EF implementing Generic repository

阅读更多关于 Not finding .Include() method in my EF implementing Generic repository

I am using Generic repository to wrap DbContext and DbSet classes from upper level. However, when in certain queries I need to use ".Include()" method to include navigation properties. But I am unable to find these methods on repository methods returing IQueryable Like, this.repository.GetQuery<GeneralCalendarDates>() this doesn't have include method, though I can use .ToList() here. Any idea what could be wrong here? Include for IQueryable<T> is an extension method that is implemented in namespace System.Data.Entity in the assembly EntityFramework.dll . So your project must reference this

What type to return when querying multiple entities in Repository layer?

阅读更多关于 What type to return when querying multiple entities in Repository layer?

I have the following layers involved in this question: Service Layer (Using IoC to call Repository) Domain Model (POCO / Domain Entities, defined repository Interfaces) Repository Layer (EF .edmx and implemented repositories) A lot of times it's really straight forward: Repository layer queries database via Entity Framework and returns IList<SomeDomainEntity> to caller which was Service Layer. The type returned is a type defined in the Domain Model. The problem I'm running into is when I need to query across POCOs A,B, and C and get data from all to be returned. Since I don't handle any logic

I need some clarification on the MVC architecture and the three-tier architecture

阅读更多关于 I need some clarification on the MVC architecture and the three-tier architecture

问题 I've been reading the book Pro ASP NET MVC Framework and I'm getting really confused with a lot of things. I've been trying to do some research but I'm finding that with so many different approaches and concepts being thrown at me, it's just making things worse. So I have a few questions: I know MVC is supposed to split the functionality into three main things: Model -> Controller -> View. Is the MVC a different approach than the three-tier architecture? Or am I still supposed to be thinking

using UnitOfWork and Repository Pattern with Entity Framework

阅读更多关于 using UnitOfWork and Repository Pattern with Entity Framework

问题 I'm gonna to use repository and UnitOfwork in my data access layer to do this take a look at one contact aggregateroot public interface IAggregateRoot { } this is my Generic repository interface : public interface IRepository<T> { IEnumerable<T> GetAll(); T FindBy(params Object[] keyValues); void Add(T entity); void Update(T entity); void Delete(T entity); } and my POCO Contact class in Model public class Contact :IAggregateRoot { public Guid Id { get; set; } public string Name { get; set; }