Reputation:
I have 2 tables, for now as an example, ClientOrder and Products Table. Using Linq, I have been able to write all the queries that I want to run 1. Search by Client order 2. Search by Client name 3. Search by Product name 4. Search by Product ID
I want to create methods for each of the above queries. The ? is, what pattern is appropriate here? Factory Pattern does not seem to fit the bill as I know that each of my object will be using the same data context.
Is it wiser to just create a static class with the 4 static methods?
Note: I am 5 months in with the programming world and a newbie
Upvotes: 0
Views: 325
Reputation: 1973
First of all, let's review the intent for the Factory method pattern:
Define an interface for creating an object, but let subclasses decide which class to instantiate. Factory Method lets a class defer instantiation to subclasses.
Does it applies to your problem? You are more concerned about how you'll be managing queries than the creation of your domain objects.
IMHO, I would avoid any implementation alternative that involves a static class/method: you cannot inherit from a static class so you're limiting the extensibility of your model. The same goes to static methods in non-static classes: they cannot be overridden in subclasses.
I wouldn't go adding those query methods to your domain objects as well. Keeping in mind that you're using OOP to model the real world, does it makes sense asking an Order to search for another orders?
Let’s think of it: in the real world, you use an order to get specific info out of it (its date, client's name or product involved). When you want to look for an order, you go wherever you store them and look for it (say, in a file cabinet). That is, you don't use an order to search for other orders.
With that in mind, you need to model this situation in your software. You already have the objects that model the order and product. What you're missing is an object that models the place you use to store orders and search for them.
In general, these kinds of objects (that save or retrieve other objects) are called repositories. In your case, it could be named ClientOrderRepository. What would this object do? Well, you already mentioned it: perform the four different queries you need. Let's see a possible definition for its interface:
public interface IClientOrderRepository {
ClientOrder FindOrderWithIdMatching(int anOrderId);
ClientOrder FindOrderWithClientNameMatching(string aClientName);
ClientOrder FindOrderWithProductNameMatching(string aProductName);
ClientOrder FindOrderWithProductIdMatching(string aProductId);
}
If you need to have only one instance of the class that will implement this interface, you can use the Singleton pattern. Don't rely on implementation choices (like the static methods one) that can be difficult to change later.
Finally, even if you find specific patterns that solve your problem, it's a good practice to think about the objects and the way they collaborate to get a task done. Use metaphors from real life to help you find missing objects or responsibilities that needs to be fulfilled. In the end, it's all about the essence of the object oriented paradigm.
For deeper info about the Repository Pattern, here are some resources to get you started:
Upvotes: 2
Reputation: 31012
I found Martin Fowler's Patterns of Enterprise Application Architecture helpful in learning how people structure access to database tables. Some of these patterns are listed here.
For your simpler task, a single class with four static methods sounds perfectly reasonable. But you should consider Fowler's Table Data Gateway pattern, where you package all the access to each table in its own class of static methods (and use a standard naming convention).
Upvotes: 2
Reputation: 59645
I suggest to extend the classes with static methods. Something like the following.
IEnumerable<Client> Client.GetByName(String Name) { }
IEnumerable<Product> Product.GetByName(String Name) { }
Product Product.GetById(Guid Id) { }
I assume you use LINQ to SQL or LINQ to Entity, so you can simply extend the generated partial calsses. If you return collections or instance, and if you choose IEnumerable
, IQueryable
, IList
, List
, or whatever depends on your needs.
Upvotes: 1
Reputation: 41837
I would probably go for a simple class (perhaps a singleton) with the methods as instance methods and call it a data access layer. Instantiate against the database required and just LINQ what i need together in the appropriate methods.
Upvotes: 0
Reputation:
If you don't know what design pattern you should use, you'd better don't use one! In this very simple case I can't think of any useful addition any desing pattern could provide. Perhaps you just want to know how you could implement functions to control those four queries and their results?
Upvotes: 2