Заводская схема против простоты использования?

Question

Фон, я расширяю членство ASP.NET с пользовательскими классами и дополнительными таблицами.

ASP.NET MemberhipUser имеет защищенный конструктор и общедоступный метод для чтения данных из базы данных. Я расширил структуру базы данных с помощью настраиваемых таблиц и связанных классов.

Вместо использования статического метода для создания нового элемента, как и в исходном API: я разрешаю коду создавать экземпляр простого объекта и заполнять данные, поскольку существует несколько объектов.

Оригинал Pattern # 1 Защищенный конструктор

> static CreateUser(string mydata, string, mydata, ...) 
> User.Data = mydata; 
> User.Update() 

предпочтительную Pattern # 2 Открытый конструктор

> newUser = new MembershipUser(); 
> newUser.data = ... 
> newUser.ComplextObject.Data = ... 
> newUser.Insert() 
> newUser.Load(string key) 

---

Я считаю, шаблон # 2, чтобы быть более простым и естественным использовать. Но метод №1 более атомарен и обеспечен, чтобы содержать надлежащие данные.

Хотелось бы услышать любые мнения о плюсах и минусах. Проблема в моем сознании заключается в том, что я предпочитаю простой CRUD/object, но я также пытаюсь использовать базовый API. Эти методы не полностью совпадают. Например, API имеет методы, такие как UnlockUser() и свойство readonly для IsLockedOut.

Я вижу, что есть несколько возможностей.

Вариант № 1 Имейте объект для сохранения/загрузки, но для этого требуется частный конструктор.

Вариант № 2 Есть объект сохранения/загрузки себя, но пусть это есть открытый конструктор

Option # 3 Одним из них является создание POCO/простой объект CRUD, а затем статические методы для обновления базы данных. ..............

Вариант № 1 Преимущества: Многопоточность безопасности «атомных», целостности объекта подрывов: Трудно использовать -> прохождение большого количества данных, возможно, потребуется обновление после создания которой потребовалось бы обертку в сделке, в некоторых случаях, так что кажется грязным

Вариант № 2 Преимущества: легкий в использовании, простой способ организовать сделки Даунсайд: Объект может или не может быть установлен соответствующим образом

Answer 1

Я предпочитаю ваш вариант # 2 лучше. Я предпочитаю объекты с конструкторами по умолчанию. Вы говорите, что вам нравится # 1, потому что он заставляет вас вводить данные, но на самом деле, вы должны иметь валидации для этого в любом случае, не так ли? Итак, если у вас есть проверки, почему бы просто не положиться на них? Если у вас их нет, тогда вставьте их! (По общему признанию, одной из основных причин, по которым я предпочитаю конструкторы по умолчанию, является сериализация, и это, как правило, легче тестировать.)

Только мои $ 0,02.