Я не знаю, что именно вы имеете в виду под myDB.CreateSpecialThing(.....). У меня есть три интерпретации:
objectContext.CreateObject<SpecialThing>()
dbContext.SpecialThings.Create() (EF> = 4,1)
SpecialThing.Create(.....) (статический метод EntityObject производных сущностей)
Третий метод - это только автоматически сгенерированный помощник, который принимает параметры (для обязательных полей), устанавливает свойства и возвращает объект. Это точно так же, как создание объекта с new и последующая установка свойств.
Первые два метода вступают в игру, если вы работаете с POCO и используете ленивую загрузку или меняете прокси отслеживания. Эти методы создадут динамический прокси объекта (который является динамическим классом, производным от вашего класса объектов), а не непосредственно объект. Ни один из этих методов не присоединяет сущность к контексту, вы должны сделать это вручную - независимо от того, используете ли вы эти методы, чтобы создать сущность или создать ее с помощью new.
Пример, в котором использование CreateObject<T> / Create может быть важным, если предположить, что объект User с коллекцией virtual Roles:
using (var ctx = new MyDbContext())
{
var user = ctx.Users.Create();
user.Id = 1;
ctx.Users.Attach(user);
var roles = user.Roles;
}
Использование virtual включает отложенную загрузку для коллекции Roles, а приведенный выше код загружает все роли пользователя 1 (или пустую коллекцию, если у пользователя нет ролей). Использование new с другой стороны ...
using (var ctx = new MyDbContext())
{
var user = new User { Id = 1 };
ctx.Users.Attach(user);
var roles = user.Roles;
}
... не позволяет лениво загружать коллекцию, поскольку user не является динамическим прокси-объектом. roles будет null, независимо от того, есть ли у пользователя роли или нет.
Итак, я бы сказал, что нет опасности создать сущность с new. Вам просто нужно помнить, что у вас нет функций отложенной загрузки или отслеживания изменений прокси для сущности, созданной с помощью new.