I know this should not be trivial, but so far couldn't find the resolution...
Working with an EF4 DB-First model, using LINQ-to-Entities with POCOs which will be consumed by an MVC3 app.
I have three entities Customer, CustomerAdress and a lookup CustomerAddressType.
Customer CustomerAddress CustomerAddressType
---------- ---------------- -------------------
CustomerId (PK) CustomerAddressId (PK) CustomerAddressTypeId (PK)
LastName CustomerId (FK) Description (Values: Mailing, Billing)
FirstName CustomerAddressTypeId (FK)
MiddleInitial Address
.... City
State
Zip
StartDate
EndDate
As you can see CustomerAddress has a FK CustomerAddressTypeId, which identifies what type of address this is, i.e. Mailing or Billing.
I would like to:
Have is ability to do something like this: Customer.CustomerAddress.OfType<MailingAddress> to get the collection of mailing addresses for the customer.
Have a CurrentMailingAddress and CurrentBillingAddress properties, that would return the single instance CustomerAddress.OfType<> with the highest StartDate and EndDate in the future.
Would be also nice to take Address thru Zip properties and refactor those propertiess into a Complex Type Address.
I tried creating 2 inherited entities off of CustomerAddress (assuming it is TPH [table-per-hierarchy] strategy):
MailingAddress and BillingAddress, CustomerAddressTypeId being the discriminator. I did this in the model designer, and as soon as I tried adding a second inherited entity, it told me that the properties with those names already existed, and wouldn't let me rename them to match the properties of the first entity.
Any ideas how to accomplish this? Please dumb it down for me :)
Thanks!!!
It is not such trivial. TPH will be possible but you must place all properties to the base CustomerAddress and derive two sub entities which will not hold any property because all properties are shared (= must be in the parent). You will use CustomerAddressTypeId as discriminator and because of that you will not be able to map this field as property in the entity. I'm also not sure if you can have the field both in discriminator and association mapping (that is actually nice homework for me). If not you will not be able to map association between CustomerAddress and CustomerAddressType.
Both CurrentMailingAddress and CurrentBillingAddress are computed properties and they are not part of mapping. It is up to you to implement their logic in your partial part of Customer entity.
I don't understand the last point with Zip and complex type.
Related
I have 4 related entities:
District (id, name, municipality, zip_code)
Municipality (id, name, city)
City (id, name, province)
Province (id, name)
And I just made a domain service to get all data related to a Zip code. I need to find Districts, Municipality, City and Province related to it. So I'm injecting those 4 repos in my service. I read data from every repository, format it to (id, name) because is all the data that I need from them.
I think that there is violation of SRP, but can't find a way to do this in a better way. I have read already Refactor to Facade Service but don't think that this apply to my problem.
My questions are:
1. Should I put all those entities into an aggregation?
2. Where should be done data formating? In service in repo or another class called from service?
3. Any other better solution?
Thanks in advance
As you discovered, one repository per domain entity does not scale well. It's basically ignoring the relations between the entities.
In ddd there is a concept of an aggregate root(ar) object which is basically a master node object with associated child objects. Different domain contexts will have different ars. Functionality is usually designed around ars as opposed to individual entities.
So think in terms of having a repository support what is needed for a given ar. That means being able to do one zip code query and returning an ar consisting of a zip code root and attached districts, cities etc.
To implement you will probably need a master object containing all the individual entity database mappings as well as their relations. Again, it's the relations that are important. Each repository will have access to the complete mapping information.
You did not mention a language but in php here an example of an object relational manager that follows these concepts: http://docs.doctrine-project.org/projects/doctrine-orm/en/latest/
I'm new to CoreData structure, I have two classes one is "Person.h" and another is "Education.h" which has one to many relations ship Person<--->> Education`.
Here's the attributes for each classes,
Person.h
personID (unique) Number
pName String
pAge Number
educations Set
here, p stands for person
Education.h
educationID (unique) Number
eName String
eState Number
eStarted String
eCompleted String
eCenterName String
eBy Person
here, e stands for education
Ok, now I want to fetch (all / some) education details for a Person. I've successfully inserted records in both the classes with proper inputs. How to get this done? Any suggestion? Please consider me to correcting, even if this flow would not clear to you (or its wrong).
Thanks,
Hagile
Normally you'd have a Core Data relationship on Person that points to the Education entity, configured as to-many. Then once you have an instance of Person, you just look up the value of that relationship like you'd look up the value of any property. You get back a collection of zero or more related Education instances, and you don't need to do an additional fetch.
Your eBy relationship on Education suggests that you're thinking of this as if you were working with SQL. With Core Data it's normal to have a to-many relationship defined on the entity that has the relationship (and indeed, eBy should really have an inverse relationship).
Consider the following schema: Employee, and EmployeeType. Employee has a fk to EmployeeType (EmployeeType might have fields like EmployeeTypeId, Description, etc...).
Now I would like to use EF's inheritance feature to create objects HourlyEmployee, and SaleriedEmployee based on the Employees fk field.
This does not seem possible. Every avenue I have tried has failed. Since Employee's FK is the descriminator for the mapping to the derived entities HourlyEmployee and SaleriedEmployee and the FK to the table EmployeeType.
Is there anything I can do short of adding a seprate field in Employee that is an duplicate of the fk field?
I have the following Models
DeltaDirectionType,
int Id
string Name
Delta,
int Id
string Name
DeltaDirectionType DeltaDirectionType
Double Value
Trade
int Id
DateTime BusinessDate
IList<Delta> deltas
So DeltaDirectionType is a lookup table, Trade holds a collection of Deltas
In the database it is implemented as follows
DeltaDirectionTypes
Id int
Name varchar(max)
Deltas
Id int
Name varchar(max)
DeltaDirectionType_Id int
Trade_Id int
Value float
Trades
Id int
BusinessDate DateTime
Delta_Id int
When I generate the model from code for the Edmx file, and (un check the foreign keys) as my model does not have properties for these. I am having problem with the navigation properties. Something like this in nHibernate would be a simple one to many mapping for the DeltaDirectionType and Delta and a many to many for Delta and Trades however, how do I firstly get it to recognise that DeltaDirectionType is a lookup and secondly get the Icollection to work for me.
I am struggling with this, Entity Framework does not make it easy for you. I have tried the usual, delete the navigation property that EF puts in for you on one side, but then you get some mapping fragments errors, properties not mapped etc.
Please help or point in the right direction.
Lookup tables are real life problems, not sure why it is so hard withing EF to implement.
Any help much appreciated
Thanks
You must either create foreign keys or navigation properties in the model to navigate the relationship.
Navigation properties can be defined as one-way, ie from the deltas table to the look-up table. A one-way navigation like this would add the appropriate property to the delta's object but not to the looup table
What you actually mean by lookup? Do you except that Delta entity will have DeltaDirectionType_Name directly mapped?
In EF you will get navigation property to DeltaDirectionType and you can access the name through this navigation property. If you don't like it you can add new property to partial class of your generated POCO and provide the Name directly in Delta entity like:
public string DeltaDirectionTypeName
{
get
{
return DeltaDirectionType != null? DeltaDirectionType.Name : String.Empty;
}
}
The only problem is that you can't use this property in Linq-To-Entities queries. In queries you always have to use navigation properties.
I am trying to create a TPH inheritance hierarchy using foreign keys / navigation properties as discriminators and I am having some trouble getting it right.
I have the following entities:
Person:
Id (int)
Name (nvarchar)
PlaneId (int)
CarId (int)
Car:
Id (int)
Name (nvarchar)
Plane:
Id (int)
Name (nvarchar)
with PlaneId and CarId beign FKs. I have corresponding tables in a database and I can create a conceptual model using the VS2010 EF wizard. The Person entity then has two navigation properties, Car and Plane.
Now I want to derive two types from Person:
Pilot (condition: PlaneId is not null)
Driver (condition: CarId is not null)
So, I add the entity Pilot, tell it to map to Person and add the condition PlaneId is not null. At this point Visual Studio (or edmgen I guess) complains that the property Person.PlaneId with 'IsNull=false' condition must be mapped.
What is my next step? I have tried various approaches, but can't seem to get it to work. Any insight would be greatly appreciated.
You can't do that. Discriminator columns must be non-nullable.