Robert,
I have used this extensively lately, with no problems what so ever. Problem is when you Merge Schema Changes or refresh things in the ORM Wizard, you lose all of it, but, here you go...I HATE that the ORM has Partial Class Generation, so I always turn it off. Class files should be all-inclusive, defining both the Private and Public properties and fields.
I generated the below class as an example from a working project. I left _countryId and _stateId as they were for a reason, please ignore them for now. The field/property _job is what I will be discussing. By default, this is how the ORM reverse maps items in your database because it knows that the column "job_id" in the JobOrigin table references the Jobs table, via the FK constraints. Of course, you know this great because it makes it truly Object-oriented, but sucks for those apps that aren't OO. Take a look, _job Gets/Sets a Job object, not an integer (which you already know):
Now, take a look at the app.config file. The snippet for the above class:
Notice how the <field name="_job"> is setup. This, in combination with the class file, is how the ORM determines what to do with the values. If you want BOTH a _job As Job Object property AND a _jobId As JobId Integer property, simply make the app.config file look like:
I indented the new field for visual reasons, <field name="_jobId">. This tells the ORM code that whatever property in your class file has the FieldAlias attribute of "_jobId" maps to the job_id column in the database. now, make your class file look like:
Notice I added a Private _jobId As Integer, in the upper portion of the class file - right after the Private _job and a Public Property JobId As Integer at the end of the class.
Now when you build, you can reference the JobOrigin.Job and the JobOrigin.JobId. Mine is not read-only, because I use a lot of drop downs to the set the JobId value...and so far with 300 classes throughout many projects, things are working just fine. Whether you would have an inconsistency or not depends 100% on what you are doing and how your code works, so I take no responsibility if there is a consistency problem. I can only vouch for what my apps do. One could actually make objects smart enough to never have consistency problems, but they would violate domain model and n-tiered layer access rules...even though the object would be much smarter.
So, to recap what I did:
1. Add field mapping definition to app.config.
2. Add Private declaration to <objectclass>.vb file.
3. Add Public declaration and Get/Set methods to <objectclass>.vb file.
4. Build and use.
Now, to elaborate on what you might be doing, since you said you could use a read-only property. You would do the same things as above (or at least I would), but you could declare the Public property read-only and the Get method would look like:
I don't know what your classes look like or what your DB looks like, so the above example may be inaffective. All my classes/tables have ID columns.
Let me know if this helps...
Mitch