This is a topic of prolonged discussion. Basically, you started to think in right direction, but still far away from well balanced approach.
First, let me offer some criticism. You first goal should be isolation of UI from "business logics". You first options is worse, because all mixed together. You formulation of the problem itself actually misses important point: you describe menu items, which are by far less important than menu actions.
First thing to do: you need to introduce a notion of action which is abstracted from the UI controls use to invoke an action. The action be invoked from any UI element you may decide.
Your second approach looks a bit better, but it will not reach your goals. 1) still you're thinking about menu items only; this is inadequate level of abstraction; and related: 2) why UI object are aware of logical objects, not the other way around? Right, the menu items (or whatever triggers the actions) act on the logical object, so the UI class holds a reference to it. But as the state of you logical object changes, the set of valid operations changes. What triggers that change? You may need to equip some "properties" describing logical objects with side effect to trgger UI representation of the object, and -- importantly -- the states of the controls user to trigger action should be invalidated. In terms of you menu items, some of the items should be enabled/disables, others probably renamed, hidden, etc. Don't forget, at the same time the logical object should be agnostic to UI controls and perhaps actions. Also, is your application multi-threading? it makes a big difference.
This way, we're running into some self-referencing deadlock in the design, from the other hand, it should bring the idea of having some intermediate agent sitting between the UI and you logical objects, some "middleman".
Working people devised different schema used to tackle such problems. You can learn them by getting familiar with some design patterns.
Here are the patterns you probably need to understand:
Model-View-Controller (MVC)
Model View ViewModel (MVVM)
Model-View-Presenter
First two are considered as architectural patterns, the last one as a design pattern, derivative from MVC, where the role of "middleman" is performed by Application Controller.
The choice of best-fitting pattern for you projects really depends on the scale of the project, its goals and other detail. It really takes experience and critical thinking.