Architektura aplikacji MVC - modele i widoki częsciowe

Mam pewien problem z architekturą aplikacji MVC i nie wiem jak się za to zabrać.

1. Mam model Comment w nim Id, Author, Content, Date. I chciałbym wykorzystać ten model do dwóch tabel. Jedna dla komentarzy a druga dla aktualności.
   Jak z jednego modelu stworzyć dwie osobne tabele?
   Próbowałem zagrywką w kontekście typu

DbSet<Comment> Comments;
DbSet<Comment> News;

Ale w metodzie Seed jest coś takiego

 context.Set<Comment>().AddOrUpdate(x);

co odnosi się do modelu a nie tabeli?

2. W każdym poradniku, tutorialu i książce o ASP.NET jaką czytałem w modelach, kontekstach i klas operujących na kontekście wszystko jest public ... {get; set;} nie ma żadnej kontroli dostępu. Czy to dobrze? Czy nie ma sposobu by dostać się do tych metod spoza aplikacji?

3. Wracając do punktu 1. Mam HomeController a w nim About oraz Index w obydwóch tych akcjach chcę wyświetlać inne tabele.
   Jak się za to zabrać? Stworzyć w kontrolerze dwa obiekty dostępu do tabel?
   Stworzyć widoki częściowe i wyświetlać w danym miejscu?

Nie proszę o gotowe rozwiązania tylko o tematy którymi mógłbym się zainteresować ;)

Ad 1) To nie jest problem z MVC lecz z EF. Szukaj informacji o tym, jak zdefiniować nazwę tabeli w Code First.
Ad 2) Spoza aplikacji? A jak to sobie wyobrażasz?
Upublicznianie wszystkiego to jest generalnie nie najlepsza praktyka, ale w przypadku obiektów DTO nie ma w tym prawie nic złego, a sporo ułatwia.
Ad 3) Obiekty dostępu do tabel twórz w warstwie dostępu do danych.
Jeśli chcesz mieć dwie zupełnie inne akcje, to do czego miałyby służyć widoki częściowe? Ich używa się po to, aby mieć jakąś wspólną część interfejsu na różnych stronach.

Dzięki za odpowiedź.

Odpowiadając na pierwsze to albo źle szukałem albo nie o to chodziło.
Za pomocą Code First DataAnnotations można ustawić nazwę dla generowanej tabeli.

Ja potrzebuje z jednej klasy POCO stworzyć dwie niezależne tabele w tej samej bazie danych.

Co do trzeciego. O ile dobrze zrozumiałem to mam dobrze?
Mam coś takiego:

1. Klasy POCO
2. Kontekst
3. Klasy operujące na DbSetach z kontekstu
4. Kontrolery wywołujące metody z klas z punktu trzeciego.

• W widokach za pomocą ActionLink przechodzę od kontrolera do kontrolera.
  Np. W HomeController -> Index -> ActionLink("Konakt", "Index", "ContactController");

Kolejne pytanie to o przechowywanie danych w bazie.
Mam jedną klasę, która reprezentuje tabele a w niej:

1. Jedenaście właściwości typu string z MaxLength(500)
2. Sześć właściwości typu int
3. Trzy właściwości typu DateTime
4. Dziesięć obiektów innych klas w tym dwa typu HashTable zawierające ok. 50 obiektów innych k

Rozbić na mniejsze klasy? Przy projektowaniu głównym czynnikiem była prostota operacji. Jak to może się przenieść na wydajność aplikacji lub pojemność w bazie?