Как инициализировать класс? - PullRequest
6 голосов
/ 22 октября 2009

Проблема действительно проста, у меня есть класс «Stock», я хочу загрузить его свойство «StockName», «StockCode» из БД.

так какой паттен мне использовать?

шаблон 1) Используйте класс обслуживания для его создания


 public interface IStockService{
             Stock GetStock(string stockCode);
             void SaveStock(Stock stock);
         }
         public class StockService : IStockService{
         }

         IStockService stockService = new StockService();
         Stock stock = stockService.GetStock();

шаблон 2) Использовать статический метод на складе


        public class Stock{
            public static Stock GetStock(){
                Stock stock = new Stock;
                //load stock from db and do mapping.
                return stock;
            }
            public void Save(){
            }
        } 

шаблон 3) Используйте конструктор для загрузки

        public class Stock{
            public Stock(){
                //load stock from db and do mapping.
                this.stockName = ...
                this.stockCode = ...
            }
        }

для шаблона 1: кажется, что для создания стокового объекта используется так много кода, а метод SaveStock кажется немного неориентированным на объект.
для шаблона 2: метод «Сохранить» выглядит нормально, но метод GetStock является статическим методом, кажется, что класс Utility всегда использует статический метод.
для шаблона 3: конструктор будет загружать данные из базы данных при инициализации. кажется, что он также сбит с толку.

Ответы [ 8 ]

5 голосов
/ 22 октября 2009

шаблон 2) является шаблоном фабрики (метода) и напоминает мне о синглетонах (static = singleton). Примечание синглтоны - зло . Заводской метод не является полиморфным. Вы не можете изменить это для тестов (то есть вы не можете издеваться над этим). Это зло! Избегайте этого!

шаблон 3) нарушает то, что конструктор не должен делать слишком много. По моему мнению, запрос к базе данных - это слишком много для ктора. Объект и его создание - разные проблемы и должны быть разделены. Дальнейшее дальнейшее создание экземпляра должно быть отделено от экземпляра, поэтому попробуйте использовать фабрики (или инжекторы). Вы можете заменить фабрику проще, чем «новый класс», распространяемый через ваш код.

шаблон 1) остается, который является абстрактным фабричным шаблоном. Это хорошо. Вы можете использовать другую реализацию для тестирования (макет). Это отделяет создание от объекта. (Принцип единой ответственности, как называет его Карл Бергквист.)

Так что я бы пошел с рисунком 1.

2 голосов
/ 22 октября 2009

Шаблон 1:
- проще тестировать
- принцип единоличной ответственности
- Может потребоваться больше кода.

Шаблон 2:
- Статические классы / методы могут сделать насмешку намного сложнее. Я стараюсь избегать этого столько, сколько могу.

Шаблон 3:
- Хорошо для маленьких классов. Но держите логику подальше от конструктора

Но я думаю, что Orm и сериализация охватывают большинство частей (создание объектов).

1 голос
/ 22 октября 2009

Вам не хватает важной части. В частности, где вы получаете строку подключения для связи с базой данных?

Обновите каждый из ваших примеров, откуда взята строка подключения, и я думаю, что это даст правильный ответ.

0 голосов
/ 22 октября 2009

вы должны разделить класс сущности (stock) и логику, которая его заполняет (stockservice), но вместо написания класса stockservice просто используйте orm, чтобы отобразить db в ваш класс сущности (stock).

0 голосов
/ 22 октября 2009

Если вы хотите, чтобы он был инициализирован автоматически, используйте статический конструктор, который был вызван загрузчиком классов .net service.

0 голосов
/ 22 октября 2009

Я бы пошел с шаблоном 1. Он представляет четкое разделение проблем между моделью предметной области и доступом к данным. Также проще провести юнит-тест.

0 голосов
/ 22 октября 2009

Лично мне нравится, когда мои объекты абстрагируются от их источника данных, поэтому я бы выбрал такой метод, как # 1. # 3 вы определенно не хотите делать ... слишком большая обработка в конструкторах может привести к неприятностям. Предпочтение № 1 по сравнению с № 2, скорее всего, сводится к тому, насколько «загруженным» вы хотите, чтобы ваши объекты данных были.

Если вы когда-нибудь предвидели получение своего объекта из другого источника данных, вам нужно придерживаться # 1, поскольку это обеспечивает гораздо большую гибкость.

0 голосов
/ 22 октября 2009

что-то похожее на метод 1, где вы должны вызывать классы уровня БД, чтобы загрузить объект оттуда, хотя вы можете использовать ORM, чтобы позаботиться обо всем доступе к данным для вас

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...