Is this even possible?

[rmagruder]

I've been all over the 'net looking for an answer to this and can't find it, so maybe I'm looking wrong. Here's what I want to do, and I'm not able to get it working right with Entity Developer - but maybe it's a EF limitation.

I have a Model-First model, and it needs to coexist in a database with pre-existing tables. Say I have my entity called "Coupon" and it's my generated table. Elsewhere in the database is an "Order" table that will have any # of coupons. I want to have a property on Coupon called "OrderNumber". I don't really want to store it in the table. I effectively want my entity model to query Order table and return the Coupon Entity with the Order number in it as if it were part of the Coupon table, even though it isn't, and it's not updatable either. I've been looking at computed columns, joining with the other table using a Defining Query, trying to do Entity Splitting, etc, and I'm still really not getting there.

A lot of this comes from not wanting to impact existing tables. They are really only there for lookup purposes. I don't want the consumer of my service to be trying to update or change anything about Order -- but I want them to have that Order number for a particular coupon.

The architecture for this is Web API 2 OData -> EF Model First -> Oracle.

If anyone can help me with a strategy whereby the consumer gets the Order Number, or how I can add an existing table to the model without screwing things up from a database generation or update standpoint, I'd love to know what it is...

Signed, an exhausted google searcher
Randy

[Shalex]

Say I have my entity called "Coupon" and it's my generated table. Elsewhere in the database is an "Order" table that will have any # of coupons. I want to have a property on Coupon called "OrderNumber". I don't really want to store it in the table.

Why don't you want to create the "OrderNumber" column in the "Coupon" table which will be generated in the database by your code?

[rmagruder]

I actually don't have a problem with that, and it's one of the better ideas.

I think the issue I'm having, if I do that, is figuring out the appropriate approach to take to putting it in. The candidates are: The OData enabled Controller class in the Web API Project, or the Entity model class?

I get very nervous about modifying an OData-enabled controller because I don't want to break standard OData REST URL's by adding customizations to it unless I know exactly what I'm doing.

[Shalex]

I think the issue I'm having, if I do that, is figuring out the appropriate approach to take to putting it in. The candidates are: The OData enabled Controller class in the Web API Project, or the Entity model class?

As I understand, views and controllers are generated basing on the entity model classes.
Could you please clarify your question?

[rmagruder]

They are. I'm just trying to figure out where the 'brains' of this kind of stuff would reside. You could hand roll a Controller action to manipulate the entity model to do a fair bit of work, or you could just make the Entity Framework code smarter by having entities with more complex mappings and queries behind them.

I don't like putting too much knowledge in the Controllers, though.