This thread looks to be a little on the old side and therefore may no longer be relevant. Please see if there is a newer thread on the subject and ensure you're using the most recent build of any software if your question regards a particular product.
This thread has been locked and is no longer accepting new posts, if you have a question regarding this topic please email us at support@mindscape.co.nz
|
Howdy All, I have a situation where I need to get data from tables in two different schemas in my Oracle database... First Question: Is it better to create two models in my VB.Net solution (one for each schema/connection) or use just one model and bring the tables in from the two different connections into the one model? Second question: And this might influence the decision of the first question... Due to the nature of the project, I need to build the Context up in code. The project is an Add-In for another app, so I do not use the app.config xml file to build up the context and other connection properties, In past projects where I had only one connection/schema, I had only one context and I built that in code... So now to my question... Do I use TWO contexts, one for each schema/connection, or just one??? and if it's just one, had do I set the connection properties for it, for the different usernames and passwords for the schema connections??? :-) So I see the possiblity of three different solutions: One Model and one Context that somehow handles both schemas and connections, One Model and two contexts, one for each schema/connection, and Two Models with one context each, one model for each schema... Or is there a better way??? :-) Thanks in advance, Kevin Orcutt GIS Developer/Consultant City of Cincinnati - Cincinnati Area GIS (CAGIS) (513) 850-1335 (cell) Kevin.Orcutt@cincinnati-oh.gov www.cagis.org |
|
|
There is nothing wrong with having different schemas per entity in your model, and we certainly support this. If your entities are logically part of the same model (e.g. they might have a relationship, or you want to maintain them together within the same UnitOfWork) then you should represent these on a single model. If you want to isolate them then split these on to a seperate model and have a second context. Each additional UnitOfWork being created is an additional database connection so bear that in mind if you do go down the path of maintaining multiple contexts and UnitOfWork instances.
|
|