Заводская модель против простоты использования? - PullRequest
1 голос
/ 18 марта 2010

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

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

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

Оригинал Шаблон № 1 Защищенный конструктор

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

Мои предпочтения Шаблон # 2 Публичный конструктор

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

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

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

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

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

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

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

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

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

1 Ответ

1 голос
/ 18 марта 2010

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

Всего лишь мои 0,02 доллара.

...