将非结构化重复代码重构为可重用组件的技巧

发布于 2024-10-12 17:54:39 字数 1808 浏览 2 评论 0原文

我查了又查,没有得到任何相关的答案。希望有人可以提供帮助。

我开始编写类作为一种保存数据的单元,并编写另一个 util 类来从数据库填充该类。好吧,对于小型代码库来说,这似乎不是什么大问题,但展望未来,对于我来说,成长为一名有能力的开发人员,牢牢掌握面向对象的设计和开发,我需要将其发展为适当的设计

让我们开始最初的课程

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;
   }
}

谢谢

I have searched and searched and could not get any relevant answer. Hopefully someone can help.

I started writing classes as a sort of unit hold data and another util class to populate the class from the database. Well this might not seem to big of a problem for a small code base but looking forward and for me to grow to a competent developer with a solid grasp of object orientated design and development i need to grow this into a proper design

Lets start of with the initial class

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 ;
   }

}

My question is what is the best way to move forward from this design.

Edit
At the moment the Util class is a big mess and i need advice how to extract and group the functions together follow a structured design

This is not going to work, or can it

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;
   }
}

Thanks

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

怂人 2024-10-19 17:54:39

我的问题是,推进此设计的最佳方式是什么。

名为 UtilManager 的类或您拥有的其他类通常具有设计味道。您应该能够描述该类正在做什么(它应该具有单一职责),并且这应该是该类的名称。如果你必须使用通用的、模糊的、包罗万象的术语来描述类正在做什么,那么你就做错了,需要重新设计。

您的 Util 类做得太多了。它从数据库中获取两种不同类型的数据。通过以这种方式设计类,您将违反开放/封闭原则(每次向模型添加新类型时都必须修改此类)。

至少,您需要单独的类来从数据库获取 FooNotRelatedToFoo。 等等怎么样

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。如果您真的想深入了解,请尝试企业应用程序架构模式(Fowler)和设计模式(Gamma 等人)

My question is what is the best way to move forward from this design.

Classes named Util or Manager or what have you are generally a design smell. You should be able to describe what it is that the class is doing (it should have a single responsibility) and that should be the name of the class. If you have to use generic, vague, catch-all terms to describe what the class is doing then you are doing something wrong and a redesign is in order.

Your Util class is doing too much. It's getting data from a database for two distinct types. By designing your class in this way, you are setting yourself up to violate the open/closed principle (you will have to modify this class every time you add a new type to your model).

At a minimum, you need separate classes to get Foos and NotRelatedToFoos from a database. How about

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() {
    }
}

etc. What's really sick is that you can even lift a lot of the repetitive code of hydrating an object from an IDataReader into a common class (hint: a first version would use reflection).

Beyond this, read about SOLID. And if you really want to dive it, try Patterns of Enterprise Application Architecture (Fowler) and Design Patterns (Gamma et al.)

甜宝宝 2024-10-19 17:54:39

访问数据库的常见方式是通过数据访问对象。 http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

不知道,是否有其他类用于保存、更新或删除数据,但我通常通过 DAO 进行 CRUD 操作。

the common way to access the database, is through data access objects. http://java.sun.com/blueprints/corej2eepatterns/Patterns/DataAccessObject.html

Don't know, if you have other classes for persisting, updating, or deleting data, but I usually do CRUD operations through a DAO.

怪我鬧 2024-10-19 17:54:39

您的 Util 类负责很多事情(正如 Jason 之前指出的那样)。

看来,问题的关键在于,Util 试图成为 FooUnrelatedToFoo 对象的存储库。

我个人会考虑将其抽象为一些继承结构并引入泛型。

如果您要创建大量以重复且基于约定的方式映射到数据库表的 POCO 对象,请考虑使用 ORM,例如具有 FluentNHibernate 映射的 NHibernate。

Your Util class is responsible for many things (as Jason pointed out earlier).

It appears though that at the crux of it, Util is attempting to be a repository for your Foo and UnrelatedToFoo objects.

I would personally look at abstracting this out into some inheritance structures and introducing generics.

If you're going to be be creating a lot of these POCO objects that map to database tables in repetitive and convention based ways, consider an ORM such as NHibernate with FluentNHibernate mappings.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文