Exactly what kind of relationship exists between a Hybrid Entity and its GameObject?

(In the instance of using a GameObject that has a GameObjectEntity component attached) Is the GameObject merely a template for the corresponding Entity to be spawned in as? Or is the GameObject actually necessary for that Entity to function?

Furthermore, the Entity that is created from the GameObject is an exact duplicate of it -- even including components that are MonoBehaviours (such as Transform, BoxCollider, Rigidbody, etc), are these components just for iterating over? If I am not mistaken, when these components values are changed they no longer are accurate representations of the template GameObject's components (Sans Transform, as GameObjectEntity keeps them in sync)... Does this mean that the GameObject's components only exist for this initialization?

TL;DR:
What is a GameObject's purpose other than for Hybrid Entity initialization? Is there actual communication going on between the two? Is it necessary to have a corresponding GameObject for a Hybrid Entity to function, or is it just a visual representation of the Hybrid Entity?

EDIT:
An answer has been provided by GilCat on another thread with correct (or auxiliary) information:
https://forum.unity.com/threads/get...re-null-or-some-other-related-problem.630355/

 

It's a template. Entity doesn't need a gameobject to exist.
There's some systems that do sync transformations from Position / Rotation / Scale components to the transform, but that's it. (I think?)

 

Wow, that was fast!

Yeah, I've heard people say the same thing... But could a Hybrid Entity run perfectly fine without a GameObject at all despite there being MonoBehavioural components on the Entity? (I suppose "component" isn't the proper word though, as something such as a Rigidbody component isn't really a component by ECS standards). My question being specifically -- do all of these "MonoBehavioral components" attached to an Entity run flawlessly despite them being, well... Not really ECS components?
(To tell you the truth i always thought entities couldn't be comprised of these non-ECS components as the components wouldn't function. If this isn't the case then i am totally going to go through the roof)

 

Yes, they do. Monobehaviours exist separately from ECS, so does entities from classic monobehaviours.
They can communicate however, and you can store the entity created by the EntityManager in Monobehaviour.
This provides a way to read / write (.AddComponent/.GetComponent) data from the ECS to the classic approach.

Same applies to Systems. Systems can communicate with other scripts in your application in their .OnUpdate method.
(It's always runs on the main thread).

Upon entity instantiation only actual components and data from ComponentDataWrapper / SharedDataWrappers are transferred.

 

Hmm, how interesting! Thank you so much for your detailed answers as this was a question i have been muddling over for a while now.

Cheers!

EDIT: Not sure if it'd be right to make a new thread or not (considering my previous question was answered so swiftly) but has anybody had any success creating an Entity that is partially comprised of MonoBehavioral components (Such as Rigidbody) purely through code instead of through prefabs? I know it's possible to do, but i myself am yet to do it successfully (which is the main reason of this threads existence as i wanted to cement what i already knew about Entities and GameObjects).