I have two databases that are almost identical in schema but seperate in the data that is held within them. The consuming application does not need to know about these differences so I am creating a service which will have the entity framework models but I want it to return a single type back. For example:
**DatabaseA** -> EFModelA
- Customers
- Orders
**DatabaseB** -> EFModelB
- Customers
- Orders
I want to be able to return a Customer class through the a call rather than it returning either EFModelA.Customer or EFModelB.Customer.
I have have looked into two ways of doing this but can't work out which way will provide the least resistance in terms of maintenance. They are:
Create a unified view of the data in DatabaseA which unions the data from DatabaseB so they application only sees one entity set. The downside is working out how to make sure that they keys are unique but I can add an extra field to denote which database it came from.
Have 2 separate EF Models and have some way of scripting (e.g. T4 templates) a combined model of equivalent types and then implemented mapping code between the two EF types and the combined type.
Has anyone else come across this problem and how have you solved this? If not, how would you tackle this problem?
Related
Let's say I have a project where I use Entity Framework, but I want to use my own classes instead of the EF classes.
Reasons for using my own classes:
Easy to add properties in code
Easy to derive and inherit
Less binding to the database
Now, my database has table names like User and Conference.
However, In my domain project, I also call my files User.cs and Conference.cs.
That means I suddenly have two objects with the same naming, which is usually very annoying to work with, because you have to use namespaces all the time to know the difference.
My question is how to solve this problem?
My ideas:
Prefix all database tables with 'db'. I usually do this, but in this case, I cannot change the database
Prefix or postfix all C# classes with "Poco" or something similar
I just don't like any of my ideas.
How do you usually do this?
It's difficult to tell without more background but it sounds like you are using the Entity Framework designer to generate EF classes. This is known as the "Model First" workflow. Have you considered using the Code First / Code Only workflow? When doing code first you can have POCO classes that have no knowledge of the database, EF, or data annotations. The mapping between the database and your POCOs can be done externally in the the DBContext or in EntityTypeConfiguration classes.
You should be able to achieve your goal of decoupling from EF with just one set of objects via code first.
To extend the above answer, the database table name User (or Users as many DB designers prefer) is the identifier for the persistence store for the object User that's defined in your code file User.cs. None of these identifiers share the same space, so there should be no confusion. Indeed, they are named similarly to create a loose coupling across spaces (data store, code, development environment) so you can maintain sanity and others can read your code.
I have an entity (A) with an association (B) and I want to load and transform all of those in DTO's (with less fields than their corresponding entities). So I want a similar structure of ADto's, each with an associated BDto. Can you do that with one query (preferably QueryOver-style)? Also it would be ideal if the BDto's are reused if the represent the same entity.
I usually do this for a single entity with ISession.QueryOver<...>().SelectList(...); but don't know if this works for associations as well.
If you need associations in your DTOs, you have to manually provide them. Possibly this link could give you some ideas:
http://netpl.blogspot.com/2010/12/generic-dto-model-and-other-silverlight.html
Basically, the idea is to have a generic wapper-model for your DTOs so you'd put both ADtos and BDtos there, however because of the way the model is created (a set of dictionaries) it's easy to cross reference dtos.
This doesn't have anything in common with NHibernate though, the idea is more general.
I'd not planned for this as the requirement has only just emerged but Using Entity Framework we have pairs of tables (I'll call them Twins, A & B) with identical data structures but different names. This of course maps through via EF as pairs of objects of different types.
What I'd like to do is pretend I only have one table/object and have a switch somewhere (in the repository perhaps) that I can throw to get the data from the B group of tables rather than the A group.
I can't figure out whether there is a useful route using the repo, using structuremap and or polymorphism to enable this to work.
Al alternative might be to put the twin 'B' tables in a second database, and with the same name as their 'A' twin, if that would help at all ?
(Up until today I thought I had two different databases with no crossover and just needed to implement a connection string switch - turns out thats not the case as 80% of the tables are shared between the two states and its just the 3 or 4 that are twinned)
I would implement this through a combination of dependency injection and polymorphism.
Rather than operating directly on the entities (let's call them TwinA and TwinB), I would create the following types...
(pardon the name...not much contextual info in the question)
TwinModel (a projected type of the actual entities..hence view model)
Then, you would have...
ITwinRepository
TwinReposotoryImplA
TwinRepositoryImplB
Depending on the need, the correct Repository would be bound at runtime using structure map (through binding configuration). The implementation differences would be to leverage one Entity set over another (TwinA or TwinB).
From a coding standpoint, you're still coding against ITwinRepository and operating on TwinModel, so consumers won't need be affected with future changes, should you decide to implement a TwinC table. :O
I've found that creating two databases, generating the EF objects from the 1st, then in the 2nd dropping the common tables and replacing them with views back to the 1st with the same name works just fine. This then allows me to quite simply pick up the right connection string in the repository (although swapping repo's with structuremap would probably be neater).
So I'm just getting started with Entity Framework. I'm working with a very large, existing database. I find myself wanting to use EF to create models that are "slices" of the whole database. These slices corresponde to 1 aspect of the application. Is that the right way to look at it, or should I try to model the whole database in 1 EDMX?
Let me give you a fictional example:
Suppose that 1 of the many things that this database contains is customer billing information. I feel like I want to create an EF model that just focuses on the tables that the Customer Billing module needs to interact with. (so then that model would NOT be used for other modules in the app, rather, those same tables might appear in other small EF models). This would allow me to leverage EF's conceptual model features (inheritance, etc) to build a view that is correct for Customer Billing, without worrying about that model's effects, on say Customer Support (even though the 2 modules share some tables)
Does that sound right?
It sounds right to me. The point of an Entity Model, after all, is to provide a set of persistence-capable business objects at a level of abstraction that's appropriate to the required business logic.
You should absolutely create entity models that support modules of the application, not models that copy the underlying database schema. As the link above describes, separating logic from persistence is one of the primary purposes of EF.
I would prefer to use a slice approach, based of following reasons:
If you have a massive database with loads of tables, then it would be difficult to manage massive Entity Model.
It is easier to maintain application / domain specific entities, as entity framework is not a table to entity mapping, you can create custom entities and also combine and split tables across entities.
I am beginning a new project, so one of the tasks given to us is to determine whether we should create one large Entity Framework 4 model (don't know how many tables yet), or split the model into separate models, one per module within the application.
If we create separate models, we'll have repeated entities within each module, but this way we have less grouped entities, less potential performance problems, etc.
So if anyone can provide insight or their experience when setting up EF models I would appreciate it. What are the pain points to be aware of?
Thanks.
imho you should consider POCOs and only use the entity models to be able to create objectcontexts.
In this way you can have the same POCOs for all modules (put them in a shared assembly) but still have different entity models in each module.
POCO = Plain Old CLR object = Regular .net class
Entity Model = Model generated by EF framework containing all objectcontexts.
POCOs in EF4: http://blogs.msdn.com/b/adonet/archive/2009/05/21/poco-in-the-entity-framework-part-1-the-experience.aspx