Советы по рефакторингу неструктурированного повторяющегося кода в повторно используемые компоненты

Question

Я искал и искал и не смог получить никакого соответствующего ответа. Надеюсь, кто-то может помочь.

Я начал писать классы как своего рода данные, хранящиеся в единицах, и другой класс утилит для заполнения класса из базы данных. Что ж, это может показаться не большой проблемой для небольшой базы кода, но я с нетерпением жду, и я перерасту в компетентного разработчика с глубоким пониманием объектно-ориентированного проектирования и разработки. Мне нужно вырастить это в надлежащий дизайн

Позволяет начать с начального класса

public class Foo
{
   public int FooID {get;set;}
   public string FooName {get;set;}
   public string FooDescription {get;set;}
}

public class NotRelatedToFoo
{
   public int SomeID {get;set;}
   public string SomeName {get;set;}
   public string SomeDescription {get;set;}
}


public class Util
{
   public Util(){} 

   public List<NotRelatedToFoo> GetNotRelatedToFoos(string SomeName)
   {
     .... DB Code to return Data from DB 

     List<NotRelatedToFoo> notfoos = new List<NotRelatedToFoo>()
     (select * from NotRelatedToFoo where SomeName like @SomeName)
     foreach var item in db
     {
       NotRelatedToFoo notfoo = new NotRelatedToFoo ();
       notfoo.SomeID = item.SomeID;
       notfoo.SomeName = item.SomeName
       notfoo.SomeDescription = item.SomeDescription 
       notfoos.Add(notfoo);
      }
      return notfoos ;
   }

}

У меня вопрос, каков наилучший способ продвинуться вперед от этого дизайна.

Редактировать В настоящий момент класс Util - большой беспорядок, и мне нужен совет, как извлечь и сгруппировать функции, следуя структурированному дизайну

Это не сработает, или может

public class Foo
{
   public int FooID {get;set;}
   public string FooName {get;set;}
   public string FooDescription {get;set;}

   public List<Foo> GetFoos(string FooName)
   {
     .... DB Code to return Data from DB 

     List<Foo> foos = new List<Foo>()
     (select * from foo where FooName like @FooName)
     foreach var item in db
     {
       Foo foo = new Foo();
       foo.FooID = item.FoodID;
       foo.FooName = item.FooName
       foo.FooDescription = item.FooDescription 
       foos.Add(foo);
      }
      return foos;
   }
}

Спасибо

Answer 1

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

Классы с именами Util или Manager, или какой у вас вообще запах дизайнаВы должны быть в состоянии описать, что делает класс (он должен нести единственную ответственность), и это должно быть именем класса.Если вам нужно использовать общие, расплывчатые, всеобъемлющие термины для описания того, что делает класс, значит, вы делаете что-то не так, и вам нужно выполнить редизайн.

Ваш Util класс делает слишком много.Он получает данные из базы данных для двух разных типов.Разрабатывая свой класс таким образом, вы настраиваете себя на нарушение принципа открытия / закрытия (вам придется изменять этот класс каждый раз, когда вы добавляете новый тип в вашу модель).

Как минимум,вам нужны отдельные классы для получения Foo s и NotRelatedToFoo s из базы данных.Как насчет

abstract class Repository<T> {
     IEnumerable<T> GetAll();
}

abstract class SqlRepository<T> : Repository<T> {
    protected readonly SqlConnection connection;
    public SqlRepository(SqlConnection connection) {
        this.connection = connection;
    }
}

class FooRepository : SqlRepository<T> {

    public FooRepository(SqlConnection connection) : base(connection) { }

    public IEnumerable<T> GetAll() {
    }
}

и т. Д.Что действительно прискорбно, так это то, что вы можете даже поднять много повторяющегося кода гидратации объекта из IDataReader в общий класс (подсказка: первая версия будет использовать отражение).

Помимо этого, прочитайте о SOLID .А если вы действительно хотите погрузиться в это, попробуйте Шаблоны архитектуры корпоративных приложений (Фаулер) и Шаблоны проектирования (Гамма и др.)

Answer 2

Ваш Util класс отвечает за многие вещи (как указывал ранее Джейсон).

Кажется, однако, что в сущности, Util пытается быть хранилищем для ваших Foo и UnrelatedToFoo объектов.

Я бы лично хотел абстрагироваться от этого в некоторые структуры наследования и ввести дженерики.

Если вы собираетесь создавать множество этих объектов POCO, которые отображаются в таблицы базы данных повторяющимися и основанными на соглашениях способами, рассмотрите ORM, например NHibernate с отображениями FluentNHibernate.

Answer 3

общий способ доступа к базе данных - через объекты доступа к данным.http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Не знаю, есть ли у вас другие классы для сохранения, обновления или удаления данных, но я обычно выполняю операции CRUD через DAO.