We Keep Coding

Data Repository Pattern Design C#

I have an entity class
public partial class Product
{
public int ProductId { get; set; }
public string ProductName { get; set; }
}
and this entity
public partial class User
{
public User()
{
this.Tokens = new HashSet<Token>();
}
public int UserId { get; set; }
public string UserName { get; set; }
public string Password { get; set; }
public string Name { get; set; }
public virtual ICollection<Token> Tokens { get; set; }
}
I have a repository pattern
public abstract class DataRepositoryBase<T> : IDataRepository<T>
where T : class, new()
{
protected abstract T AddEntity(T entity);
protected abstract T UpdateEntity(T entity);
protected abstract IEnumerable<T> GetEntities();
protected abstract T GetEntity(int id);
}
How can I call repository using generic data repository using some thing like this.<T> just using generic interface not creating new class? Thanks.
_datarepositorypattern.GetDataRepository<IProductRepository>();
_datarepositorypattern.GetDataRepository<IUserRepository>();
what i want, somthing like this.
var obj = _datarepositorypattern.GetDataRepository<IDataRepository<User>>();
//then i can access use
obj.GetEntities();
update
I already created repository
this repository can return
public DataRepositoryBase<Product> ProductRepository => new ProductRepository();
in the service class
private readonly UnitOfWork _unitOfWork;
public ProductServices(UnitOfWork unitOfWork)
{
_unitOfWork = unitOfWork;
}
Product[] IProductServices.GetProduct()
{
var repository = _unitOfWork.ProductRepository;
return repository.Get().ToArray();
}
i use this current repository method like this.
what i wanted create dynamic repository so i do not updating my repository again only updating my service class with code like this.
var obj = _datarepositorypattern.GetDataRepository<IProductRepository>();
obj.GetEntities();
just using repository repository pattern i can get dynamic repository product
var obj = _datarepositorypattern.GetDataRepository<IUserRepository>();
obj.GetEntities();
just using repository repository pattern i can get dynamic repository User.
UPDATE
I just googling this is an repositoryfactorypattern can anyone help me.

as you've written it here you need you need new classes. You specify the IProductRepository and IUserRepository
that means you need something like
class UserRepository : DataRepositoryBase<User>, IUserRepository
{
//userrepository code here
}
otherwise you would get something like
_datarepositorypattern.GetDataRepository<IDataRepository<User>>();
expecially since your datarepository class is abstract you need a concrete implementation somewhere
Update: example not using entity specific repositories
If you really want to avoid entity specific repositories you can look at breeze.
you still need something like theis
class MyContext : DbContext {
DbSet<Product> Products {get; set;}
DBSet<User> Users {get; set;}
}
but then you can call a context provider like this
public class DataRepositoryBase<T> : IDataRepository<T> {
readonly EFContextProvider<User> _contextProvider =
new EFContextProvider<User>();
public void SaveEntity(JObject saveBundle) {
_contextProvider.SaveChanges(saveBundle);
}
}
now you can just call new DataBaseObjectRepository() (or have that code in your GetDataRepository method)
maybe that is a place to start. You do need something like DbContext that tells you how to map different types to different tables.

C# Design Pattern - Best Way to Design For Many Datasources [duplicate]

This question already has answers here:
How to avoid Dependency Injection constructor madness?
(10 answers)
Closed 7 years ago.
I currently have an ASP.Net MVC 5 app that uses 3 external datasources (calls are made to external APIs, responses are deserialized, and mapped to business POCOs).
The app currently uses SimpleInjector to inject concrete repositories for each datasource into a business logic layer for consumption.
The problem is, as more datasources are added (potentially 20-30), the constructor will be huge and injecting all these repositories seems cumbersome.
Is there a better pattern/approach to consuming all the datasources rather than using different repositories?
Would a facade or some other pattern be more appropriate?
Very generic examples:
public class MyObject(){
public IEnumerable<Cat> Cats { get; set; }
public IEnumerable<Dog> Dogs { get; set; }
public IEnumerable<Fish> Fish { get; set; }
}
public class BusinessLogic{
private readonly ISourceARepository _sourceA;
private readonly ISourceBRepository _sourceB;
private readonly ISourceCRepository _sourceC;
public BusinessLogic(ISourceARepository sourceA, ISourceBRepository sourceB, ISourceCRepository sourceC){
_sourceA = sourceA;
_sourceB = sourceB;
_sourceC = sourceC;
}
private Dog MapSourceARecordToDog(SourceARecord record){
var result = new Dog();
if(record != null){
result.Name = record.NameField;
result.Age = record.Age;
}
return result;
}
private Cat MapSourceBRecordToCat(SourceBRecord record){
var result = new Cat();
if(record != null){
result.Name = record.NameField;
result.Weight = record.WeightField;
}
return result;
}
private Fish MapSourceCRecordToFish(SourceCRecord record){
var result = new Fish();
if(record != null){
result.ID = record.IDField;
result.Name = record.NameField;
}
return result;
}
public MyObject GetResults(){
var result = new MyObject();
result.Dogs = _sourceA.GetAll().Select(MapSourceARecordToDog).ToList();
result.Cats = _sourceB.GetAll().Select(MapSourceBRecordToCat).ToList();
result.Fish = _sourceC.GetAll().Select(MapSourceCRecordToFish).ToList();
return result;
}
}
public class SourceARespository : ISourceARepository{
public IEnumerable<SourceAResult> GetAll(){
return new List<SourceAResult>();
}
}
public class SourceBRespository : ISourceBRepository{
public IEnumerable<SourceBResult> GetAll(){
return new List<SourceBResult>();
}
}
public class SourceCRespository : ISourceCRepository{
public IEnumerable<SourceCResult> GetAll(){
return new List<SourceCResult>();
}
}
Update:
This is not a duplicate of the constructor madness question, because in this scenario, a class needs many different datasources, but still has single responsibility. Hence, it warrants its own explanation and answer.

You should only be injecting one repository per entity into a consumer that depends on it. You may also choose to adapt the repository with a business class intermediary.
UPDATE:
Based on the information provided in the question and the problem statement, here is one possible solution. Define your core infrastructure like this:
public abstract class Entity<TEntity, TDomainObject, TIRepository>
where TEntity : Entity<TEntity, TDomainObject, TIRepository>
where TDomainObject : Entity<TEntity, TDomainObject, TIRepository>.BaseDomainObject, new()
where TIRepository : Entity<TEntity, TDomainObject, TIRepository>.IBaseRepository
{
public class BaseDomainObject {}
public interface IBaseRepository
{
IEnumerable<TDomainObject> GetAll();
IEnumerable<T> GetAllMapped<T>(Func<TDomainObject, T> mapper);
}
public class BaseRepository : IBaseRepository
{
public IEnumerable<TDomainObject> GetAll()
{
return new List<TDomainObject>();
}
public IEnumerable<T> GetAllMapped<T>(Func<TDomainObject, T> mapper)
{
return this.GetAll().Select(mapper);
}
}
}
Define your source entities like this:
public class SourceA : Entity<SourceA, SourceA.DomainObject, SourceA.IRepository>
{
public class DomainObject : BaseDomainObject
{
public string Name;
public int Age;
}
public interface IRepository : IBaseRepository {}
public class Repository : BaseRepository, IRepository {}
}
public class SourceB : Entity<SourceB, SourceB.DomainObject, SourceB.IRepository>
{
public class DomainObject : BaseDomainObject
{
public string Name;
public decimal Weight;
}
public interface IRepository : IBaseRepository {}
public class Repository : BaseRepository, IRepository {}
}
public class SourceC : Entity<SourceC, SourceC.DomainObject, SourceC.IRepository>
{
public class DomainObject : BaseDomainObject
{
public Guid Id;
public string Name;
}
public interface IRepository : IBaseRepository {}
public class Repository : BaseRepository, IRepository {}
}
Then define an ISourceRepositoryContext interface like this and add each source repository interface here:
public interface ISourceRepositoryContext
{
SourceA.IRepository SourceARepository { get; }
SourceB.IRepository SourceBRepository { get; }
SourceC.IRepository SourceCRepository { get; }
}
Then define a default implementation for the interface:
public class DefaultSourceRepositoryContext : ISourceRepositoryContext
{
public SourceA.IRepository SourceARepository => new SourceA.Repository();
public SourceB.IRepository SourceBRepository => new SourceB.Repository();
public SourceC.IRepository SourceCRepository => new SourceC.Repository();
}
Define your result transport objects:
public class Dog
{
public string Name;
public int Age;
}
public class Cat
{
public string Name;
public decimal Weight;
}
public class Fish
{
public Guid Id;
public string Name;
}
public class MyObject
{
public IEnumerable<Cat> Cats { get; set; }
public IEnumerable<Dog> Dogs { get; set; }
public IEnumerable<Fish> Fish { get; set; }
}
Then consume the ISourceRepositoryContext in your BusinessLogic class:
public class BusinessLogic
{
protected ISourceRepositoryContext repositories;
public BusinessLogic(ISourceRepositoryContext repositories)
{
this.repositories = repositories;
}
public MyObject GetResults(string param1)
{
return new MyObject()
{
Dogs = this.repositories.SourceARepository.GetAllMapped
(domainObject=>new Dog
{
Age = domainObject.Age,
Name = domainObject.Name
}),
Cats = this.repositories.SourceBRepository.GetAllMapped
(domainObject=>new Cat
{
Name = domainObject.Name,
Weight = domainObject.Weight
}),
Fish = this.repositories.SourceCRepository.GetAllMapped
(domainObject=>new Fish
{
Id = domainObject.Id,
Name = domainObject.Name
}),
};
}
}
I've confirmed that the above compiles under C# 6.0.
I would recommend changing IRepository to IBusiness in Entity and split out the data access concerns from into an IDataAccess interface that only the IBusiness implementors receive via their constructors. And then change the ISourceRepositoryContext to ISourceEntities and change the IRepository properties in that interface to IBusiness properties instead.
The BusinessLogic class is the part that really concerns me. Are you sure this one class won't be taking on too many concerns? Is this supposed to be a UoW class?
For a more complete solution based on similar techniques, check out my answer to this other question: .NET Managing Layers Relationships

Using WCF to Communicate Interface and Customer Class

I have a simple WCF service which I wish to use to send data from client to server, I am unsure of the best way to serialize the data.
My apologies if this is a duplicate, but I think that my use of Interfaces and a customer class means that this is not such a simple case.
I have a simple class structure...
public interface IFoo
{
IBar MyBar{ get; }
String SomeInfo{ get; }
}
public interface IBar
{
String SomeMoreInfo{ get; }
}
public class Foo : IFoo
{
private IBar _MyBar;
private String _SomeInfo;
public String MyBar
{
get { return _MyBar; }
private set { _MyBar = value; }
}
public String SomeInfo
{
get { return _SomeInfo; }
private set { _SomeInfo= value; }
}
}
public class Bar : IBar
{
private String _SomeMoreInfo;
public String SomeMoreInfo
{
get { return _SomeMoreInfo; }
private set { _SomeMoreInfo= value; }
}
}
I have a simple WCF service to send this data...
[ServiceContract]
public interface IFooBarService
{
[OperationContract]
bool SendFooBar(IFoo request);
}
public class FooBarService : IFooBarService
{
public bool SendFooBar(IFoo request)
{
throw NotImplementedException();
}
}
My question is, what is the best way to send this data from client to server? Should I be using attributes or a DataContractResolver or is my class design flawed for WCF communication?

This link may help: http://blogs.msdn.com/b/domgreen/archive/2009/04/13/wcf-using-interfaces-in-method-signatures.aspx
ServiceKnownType and KnownType might be the friends you are looking for: (I have not tested this out completely, so take it with a grain of salt)
public interface IFoo
{
IBar MyBar { get; }
String SomeInfo { get; }
}
public interface IBar
{
String SomeMoreInfo { get; }
}
[DataContract(Name = "Foo")]
[KnownType(typeof(IFoo))]
public class Foo : IFoo
{
private IBar _MyBar;
private String _SomeInfo;
[DataMember(Name = "MyBar")]
public IBar MyBar
{
get { return _MyBar; }
private set { _MyBar = value; }
}
[DataMember(Name = "SomeInfo")]
public String SomeInfo
{
get { return _SomeInfo; }
private set { _SomeInfo = value; }
}
}
[DataContract(Name = "Bar")]
[KnownType(typeof(IBar))]
public class Bar : IBar
{
private String _SomeMoreInfo;
[DataMember(Name = "SomeMoreInfo")]
public String SomeMoreInfo
{
get { return _SomeMoreInfo; }
private set { _SomeMoreInfo = value; }
}
}
[ServiceContract]
public interface IFooBarService
{
[OperationContract]
[ServiceKnownType(typeof(Foo))]
[ServiceKnownType(typeof(Bar))]
bool SendFooBar(IFoo request);
}

Generally the input parameters of an operation is the data from client to server, and the return data is the data from server to client.
For complex types, you need to define Data Contracts.
When you create a new WCF project through Visual Studio, you get a set of skeleton codes with Service Contracts and Data Contracts. And you will see you should use objects of DataContract classes rather than interfaces to pass data, and there are no explicit codes of doing serialization, since this is done by run time.
Unless you had studied WCF in depth and have some edge and complex cases, you should not need to use DataContractResolver in common business applications.
There are a lot WCF tutorials from the Internet, for example, http://www.codeproject.com/Articles/627240/WCF-for-the-Real-World-Not-Hello-World

Should Repositories's services depend on each other?

Assume I have 2 entities Foo and Bar as follows:
public class Foo
{
public int FooID {get;set;}
public string FooName {get;set;}
}
public class Bar
{
public int BarID {get;set;}
public string BarName {get;set;}
public int FooID {get;set;}
}
For each entity will have its repository:
public class FooRepository
{
public IEnumerable<Foo> getFoo()
{
//do something
}
}
public class BarRepository
{
public IEnumerable<Bar> getBar()
{
//do something
}
public IEnumerable<Bar> getBar(int FooID)
{
//get bar base on foo id
}
}
Each of those repositories will have an associated service:
public class FooService
{
//depend on Foo repository
}
public class BarService
{
//depend on Bar repository
}
Now I want to make a function to see if a Foo is in used in Bar. I thought of 2 methods to implement this function:
Method 1:
public class BarService
{
private BarRepository repository = new BarRepository();
public bool isFooExisted(int FooID)
{
var bars = this.repository.getBar(FooID);
return bars.Count > 0;
}
}
Somehow, this is look like it is violating Single Responsible Principle since BarService is used to check for a Foo. So I came up with method 2:
Method 2:
public class BarService
{
private BarRepository repository = new BarRepository();
public IEnumerable<Bar> getBar(int FooID)
{
return this.repository.getBar(FooID);
}
}
public class FooService
{
private BarService service = new BarService();
public bool isFooExisted(int FooID)
{
var bars = service.getBar(FooID);
return bars.Count > 0;
}
}
I wonder is it a good idea for services depend on each other like this. Please suggest me which one of those method above is good to follow or any other method will help

I personally would avoid services using other services because sooner or later you'll get a circular reference. Having the services not depend on each other also makes for looser coupling and ease of testability. So i would go for method 1.
The problem with this approach comes when you want to reuse functionality between services. In your case you can just defer calls to the respective repository, but in more complex cases you may need to add a domain object that contain common business logic that can be re-used in the different services. For example, if you had to have a complex isFooExisted method in both services, you might do something like this (note that I have changed your code to use dependency injection to make your code more testable):
public class BarService
{
private FooEntity fooEntity;
public BarService(IFooRepository repository)
{
this.fooEntity = new FooEntity(repository);
}
public IEnumerable<Foo> getFoo(int FooID)
{
return fooEntity.getFoo(FooID);
}
}
public class FooService
{
private FooEntity fooEntity;
public FooService(IFooRepository repository)
{
this.fooEntity = new FooEntity(repository);
}
public IEnumerable<Foo> getFoo(int FooID)
{
return fooEntity.getFoo(FooID);
}
}
public class FooEntity
{
private IFooRepository repository;
public FooEntity(IFooRepository repository)
{
this.repository = repository;
}
public bool isFooExisted(int FooID)
{
/** Complex business logix **/
}
}
And for the simple case I'd just use the same repository directly and not have the domain object:
public class BarService
{
private IFooRepository repository;
public BarService(IFooRepository repository)
{
this.repository = repository;
}
...
}
public class FooService
{
private IFooRepository repository;
public FooService(IFooRepository repository)
{
this.repository = repository;
}
...
}
Hope this helps.

Class designing structure in C#

Entity Class:
public class Customer {
public int CustomerId { get; set; }
public string Name { get; set; }
}
public class Invoice {
public int InvoiceId { get; set; }
public int CustomerId { get; set; }
public string InvoiceNo { get; set; }
}
Interface:
public interface ICustomerService {
Customer GetCustomerById(int customerId);
void DeleteCustomer(int customerId);
}
public interface IInvoiceService {
Invoice GetInvoiceById(int invoiceId);
void DeleteInvoice(int invoiceId);
List<Invoice> GetAllInvoiceByCustomer(int customerId);
Customer GetInvoiceCustomer(int invoiceId);
}
Class:
public class CustomerService : ICustomerService {
private readonly IInvoiceService _invoiceService = new InvoiceService();
public Customer GetCustomerById(int customerId) {
//return customer from db
return new Customer();
}
public void DeleteCustomer(int customerId) {
var invoiceList = _invoiceService.GetAllInvoiceByCustomer(customerId);
foreach (var invoice in invoiceList) {
_invoiceService.DeleteInvoice(invoice.InvoiceId);
}
//delete customer from db
}
}
public class InvoiceService : IInvoiceService {
private readonly ICustomerService _customerService = new CustomerService();
public Invoice GetInvoiceById(int invoiceId) {
//return invoice from db
return new Invoice();
}
public void DeleteInvoice(int invoiceId) {
//delete invoice from db
}
public List<Invoice> GetAllInvoiceByCustomer(int customerId) {
//get all invoice by customer id
return new List<Invoice>();
}
public Customer GetInvoiceCustomer(int invoiceId) {
Invoice invoice = GetInvoiceById(invoiceId);
return _customerService.GetCustomerById(invoice.CustomerId);
}
}
When I create a new instance for "CustomerService". It will return an error:
An unhandled exception of type 'System.StackOverflowException' occurred
Because when I create new instance for "CustomerService", "CustomerService" will create a new instance for "InvoiceService", "InvoiceServer" also create a new instance of "CustomerServer".
1) Should I set all the methods to static?
2) "InvoiceService" will have call methods from "CustomerService", and "CustomerService" will call methods from "InvoiceSercie" too. How can I write the classes? If I set all the method to static, problem will be fixed, but I guess it is not a good solution.
Thank you very much!

You have to choose one of the classes to pass itself as a reference to the other. Let's say it's customer service:
public class CustomerService : ICustomerService {
private readonly IInvoiceService _invoiceService = new InvoiceService(this);
...
}
public class InvoiceService : IInvoiceService {
private readonly ICustomerService _customerService;
public class InvoiceService(ICustomerService customerService) {
_customerService = customerService;
}
}
Now the cycle is broken...
Another option is to use a dependency injection framework, like StructureMap or Ninject.

In general, I would recommend having less coupling between the classes. Each class should do one thing (Customer and Invoice) and then create a third class which uses both. For example, you could create a class called "CustomerInvoicer" which takes the two interfaces in its constructor and move the method "GetInvoiceCustomer" to that new class. In my experience, that will make it a lot more maintainable in the long run, as each class has a single responsibility, and your ultimate consumer only needs to use the one main class (which may have more advanced logic).
public class CustomerInvoicer {
private readonly ICustomerService _customerService;
private readonly IInvoiceService _invoiceService;
public CustomerInvoicer(ICustomerService cust, IInvoiceService inv) {
_invoiceService = inv;
_customerService = cust;
}
public Customer GetInvoiceCustomer(int invoiceId) {
Invoice invoice = _invoiceService.GetInvoiceById(invoiceId);
return _customerService.GetCustomerById(invoice.CustomerId);
}
}
Also, I would recommend using a Dependency Injection library with this approach.