eRKa

Немного странный код Вы привели. А можно увидеть код Вашего dbContext?

Если Вы используете codfirst, то таблицы связываются настройкой модели через создание виртуальных свойств у модели с указанием внешних ключей и при необходимости настраиваются атрибутами или Fluent API. Тогда данные будут подтягиваться автоматом dbContext.Bid.UserCreated.Id

Вы отвечаете на свой вопрос, прежде чем его задать)

При тестировании мокают объекты, чтобы разорвать внешние зависимости.

Необходимо мокать объекты, от которых тестируемый метод зависит, чтобы не тестировать эти самые объекты. Тогда мы будем тестировать только реализацию самого метода. Мы подразумеваем, что эти объекты работают правильно и действую так, как мы того от них ожидаем. Это значит, что мы можем настроить ожидаемое от них поведение.

mock.Setup(x=>x.Users).Returns(new List<Users>(){ ... }

Т.е. мы точно знаем, что при обращении к нашему зависимому объекту через Users нам вернется весь список наших пользователей, причем точно знаем каких. Благодаря абстрагированию от зависимостей, если тестируемый метод провалится, то мы точно будем знать, что виновата реализация метода, а не реализация зависимостей.

В случае тестирования с конкретными зависимыми объектами, мы такого сказать не сможем. Потому что мы точно не можем знать, какие сущности есть в БД, что есть соединение с БД и что сама БД нормально работает.

Чтобы увидеть какой запрос формирует Entity, в конфиг, в раздел entity, надо добавить
<

<interceptors>
      <interceptor type="System.Data.Entity.Infrastructure.Interception.DatabaseLogger, EntityFramework">
        <parameters>
          <parameter value="C:\temp\LogOutput.txt" />
          <parameter value="true" type="System.Boolean" />
        </parameters>
      </interceptor>
    </interceptors>

И как то странно Вы связь устанавливаете. Завязываете таблицу саму на себя? Указывая для таблицы связь, Вы должны указать в какой таблице будет внешний ключ на Вашу сущность. Во общем мапинг в таком виде работать не будет.

Станислав правильно сказал: смотря что называть моделью. Те классы, которые генерит EF, вполне можно называть моделями и даже добавить им логику, может даже какие-то атрибуты. Главное, чтобы все добавки не противоречили тем соответствиям, что EF установил.

У меня точно такой же вопрос стоит уже вторую неделю, только в другом контексте. Мониторинг GPS трекеров. Есть серверная часть, которая по UDP протоколу получает сообщение от трекера и которая так же имеет доступ к БД, чтоб понять кому принадлежит трекер, затем сообщение уходит на хаб SignalR для отсылки веб-клиенту. Получается что у меня два конекшина к базе, от сервера с сайтом (ASP.NET MVC) и от сервера с хабом. И тоже думаю как сделать одно соединение, чтоб базу меньше напрягать, и тоже кручусь вокруг WCF или Web API.