CODEWITHSUNDEEP
c#asp.net-mvcentity-frameworkarchitecture
James Andrew Smith
James Andrew Smith

Reputation: 1566

Data Layer Architecture with multiple datasources

I am trying to create a system that allows you to switch multiple data sources, e.g. switching from Entity Framework to Dapper. I am trying to find the best approach to do this.

At the moment I have different projects for different data layers, e.g. Data.EF for Entity Framework, Data.Dapper for Dapper. I have used a database approach but when it creates the models the information generated is coupled together and not easy to refactor, e.g. separation of models.

I have a project called models, this holds domain and view models, and I was thinking of creating Data.Core and follow the repository pattern. But then, doing this will add an extra layer so I would have Presentation / Business / Repository / Data.

I would like to know the best structure for this approach. Should I also do a code-first approach to create my database? This helps separate concerns and improve abstraction. This is quite a big application so getting the structure right is essential.

Upvotes: 4

Views: 2039

Answers (4)

bennie j
bennie j

Reputation: 739

Yes the repository pattern does bring in an extra layer. Have a look at this post for more detail information Difference between Repository and Service Layer?

RE: code-first approach to create my database

It doesn't matter how big your application is, it is a question of what else you intend to use the database for. If this database is simply a repository for this application then using code-first is fine as you are simply storing your code objects. However if you are using this database as an integration point between applications then you may wish to design the database seperately to the application models.

Upvotes: 0

TonyS
TonyS

Reputation: 238

I think you approach is correct. I'd say Presentation / business / repository / data is pretty standard these days.

I'd say the code first approach using POCOs is the preferred option today in the industry. I would advise to start creating a project containing your POCO data structures with any logic in it and take it from there. The advantage of this is that your objects model the domain more naturally. If you start with a db centric approach the problem is that, if you are not careful, you may end with objects more akin to SQL relational databases than to the real model. This was painfully evident in the first versions of .net where it was encouraged to use Datasets tighly coupled with the db and that often caused problems to work with in the business layer.

If needed you can do any complex mapping between the business objects and the db objects in the repository layer. You can use a proxy and/or a unit of work if you need to.

Upvotes: 1

jnovo
jnovo

Reputation: 5769

I'd suggest factoring your data interfaces either to the model through repository interfaces for your entities or to an infrastructure project. (I think the latter was your rationale behind creating a Data.Core project.)

Each data source will then implement the very same set of interfaces, and you can easily switch between them, even dynamically using dependency injection.

For instance, using repositories:

Model
  \_ Entities
       Entity
  \_ Repositories
       IEntityRepository    

Data.EF      
   EntityRepository : Model.IEntityRepository

Data.Dapper
   EntityRepository : Model.IEntityRepository

Then in your business you won't need to even reference Data.EF or Data.Dapper: you can work with IEntityRepository and have that reference injected dynamically.

Upvotes: 4

pmbanugo
pmbanugo

Reputation: 325

I would suggest you create your domain objects, use the code-first approach and also apply the repository pattern

Upvotes: 0

Related Questions