开发者

where to put the GetItems static method? + inheritance question

开发者 https://www.devze.com 2023-02-18 20:17 出处:网络
I have Item class: public class Item { public long Id {get; protected set;} public string Name {get; protected set;}

I have Item class:

public class Item {
    public long Id {get; protected set;}
    public string Name {get; protected set;}
}

and now I want to add a function that retrieve items from the db according to filters. This should be static method that returns Item[]:

public static Item[] GetItems(long? itemId, string itemName) {
    //Do Search in the db for items with Id=itemId (in case itemId is not null) and
    //with Name=itemName (in case itemName is not null)

    return itemsList.ToArray();
}

The question is where to put this method? 1. should I cr开发者_如何转开发eate a new class for this? How will I call this class? 2. should I put this method in Item class?

Another question: In case I want to inherit from Item class. How can I force the child classes implement such GetItems method?


I would recommend a simple repository pattern implementation. You could create a class called ItemRepository that knows about your Item object and your DAL implementation. The repository would simply call into the DAL to get any data it needs and then return business objects back to the consumer.

This is very simple to implement, and if you create an interface to go along with it (ex: IItemRepository), unit testing becomes very easy because you'll be able to mock the repository and pass it along to any object that consumes it. If you make everything static, then testing is much harder, so I wouldn't recommend it.

As for inheritance: if you want to define general method signatures and properties that should be available on every Repository object, then use an interface to specify exactly what each repository should have in common. If you want to provide a base repository skeleton, then an abstract may be more fitting.


GetItems (plural) does not, to me, sound like something that should be a member of Item (singular). Especially since Item is so simple. I would create a static utility class (the factory pattern) called ItemUtility that has GetItems.

To answer your second question: if a class inherits from Item it will also inherit any concrete implementations of its member. So if there was a LoadItem method on Item, and I made SpecialItem : Item, then SpecialItem.LoadItem() would actually just be the Item.LoadItem() code. If you want to make Item.LoadItem() overridable then you can use the "virtual" modifier on the method (which would give SpecialItem the option of doing its own thing with that method).

Item could also be an abstract class if you only intend it to be used as a boilerplate base class for other more complex classes like SpecialItem.

Another option would be to create an IItem interface, and make LoadItem (and any other required member) part of the interface definition.


The data access should go in a separate class. Data access should be stored in a separate layer than the object definition, following the Separation of Concerns concept.

If you want to force all inherited objects to implement a method, you can make it abstract.


Is there any specific reason you want to make the method static? If you want to inherit the GetItems method in your child classes, you cannot make it static. To answer your questions in order:

1) Yes. Create a new class called something like ItemManager that makes the actual call to the DB layer to get the Items. That way you are separating your Data Access code from business logic

2) You should create a method in Item Class that calls the method in ItemManager to get the actual data.

3) Mark the method you created in step 2 as virtual if you want child classes to override the method to provide their own implementation. If you want to force them to override and need no implementation in the base class itself, then mark the base class as abstract so child class must override it

0

精彩评论

暂无评论...
验证码 换一张
取 消

关注公众号