repository-pattern

I'm struggling to understand the relationship between the Repository and Unit of Work patterns despite this kind of question being asked so many times. Essentially I still don't understand which part would save/commit data changes - the repository or the unit of work? Since every example I've seen relates to using these in conjunction with a database/OR mapper let's make a more interesting example - lets persist the data to the file system in data files; according to the patterns I should be able to do this because where the data goes is irrelevant. So for a basic entity: public class Account

I have read from internet I got this points which says Interfaces is used for this Use TDD methods Replace persistance engine But I'm not able to understand how interface will be usefull to this point Replace persistance engine . lets consider I'm creating a basic(without generics) repository for EmployeeRepository public class EmployeeRepository { public employee[] GetAll() { //here I'll return from dbContext or ObjectContex class } } So how interfaces come into picture? and if suppose i created an interface why upcasting is used ? for e.g IEmployee emp = new EmployeeRepository() ; vs

I am in the process of moving to Git from SVN. In SVN I had multiple eclipse projects in a single SVN repository that is convenient for browsing projects. I was going to move to having one git repository per eclipse project but EGit suggests doing otherwise. The guide for EGit suggests putting multiple projects into a single Git repository. Looking at similar questions such as this suggest one project per repository. Which approach is best practice and what do people implement? It depends on how closely-related these projects are. Ask yourself the following questions: Will they always need to

I found two patterns which appear to have the same goal - what is the difference? http://martinfowler.com/eaaCatalog/dataMapper.html http://martinfowler.com/eaaCatalog/repository.html Andrei [the Repository is] another layer of abstraction over the mapping layer where query construction code is concentrated. The DataMapper ensures the DB side of the fence doesn't need to know about the specifics of your business logic and how the data is kept in memory by your business objects and your business side of the fence doesn't need to know how the data is stored. To illustrate, consider that your

All I am trying to find out the correct definition of the repository pattern. My original understanding was this (extremely dumbed down) Separate your Business Objects from your Data Objects Standardize access methods in data access layer. I have really seen 2 different implementation, and there are no formal examples online, the ones i have seen are tucked away in books. Implementation 1 : public Interface IRepository<T>{ List<T> GetAll(); void Create(T p); void Update(T p); } public interface IProductRepository: IRepository<Product> { //Extension methods if needed List<Product>

I am learning repository pattern and was reading Repository Pattern with Entity Framework 4.1 and Code First and Generic Repository Pattern - Entity Framework, ASP.NET MVC and Unit Testing Triangle about how they implement the repository pattern with Entity Framework. Saying •Hide EF from upper layer •Make code better testable Make code better testable I do understand, but why hide EF from upper layer? Looking at their implementation, it seems just wrap the entity framework with a generic method for query the entity framework. Actually what's the reason for doing this? I am assuming is for

I see two main "schools of thoughts" when it comes to creating larger-scale enterprise-wide apps on .NET (Winforms, WPF, ASP.NET). Some folks use the "repository pattern" which uses a repository that knows how to fetch, insert, update and delete objects. Those objects are rather "dumb" in that they don't necessarily contain a whole lot of logic - e.g. they're more or less data-transfer objects. The other camp uses what I call "smart" business objects that know how to load themselves, and they typically have a Save(), possibly Update() or even Delete() method. Here you really don't need any

I am trying to learn domain-driven design (DDD), and I think I got the basic idea. But there is something confusing me. In DDD, are the persistence model and domain model different things? I mean, we design our domain and classes with only domain concerns in mind; that's okay. But after that when we are building our repositories or any other data persistence system, should we create another representation of our model to use in persistence layer? I was thinking our domain model is used in persistence too, meaning our repositories return our domain objects from queries. But today, I read this

I've been using MVC frameworks for a short while now and I really like how the concerns are separated out. I've got into a bad habit of letting the controllers do quite a bit of work. So I'm really looking for some advice. When I first started using MVC I quite often had the controller doing manipulation on the models after database work had been done. I knew this was bad so moved that work into the models. However I'm not happy with that as I want my models to be very learn. I've done a bit of reading and I see that people are keeping their controllers and models lean by having a service

I'm trying to update a model, but get the error "The operation failed: The relationship could not be changed because one or more of the foreign-key properties is non-nullable. When a change is made to a relationship, the related foreign-key property is set to a null value. If the foreign-key does not support null values, a new relationship must be defined, the foreign-key property must be assigned another non-null value, or the unrelated object must be deleted." From what I understand from The relationship could not be changed because one or more of the foreign-key properties is non-nullable