|
You can design any method to use a predicate like that. It isn't rocket science - it's LINQ:
IEnumerable<T> Fetch<T>(Func<T, bool> predicate){
return repository.Where(predicate);
}
...as long as you are using the repository that contains type `T`.
|
|
|
|
|
I know. I use it every day. I was merely suggesting a name that attempted to describe what the OP was doing.
If they had got the hint, they might have opted to modify their Framework/Wrapper/WhateverItWasTheyCalledItICantBeArsedToGoBackAndLook.
If I had suggested changes, that would be turning The Lounge into a programming forum, which it ain't. 
Henry Minute
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
I wouldn't let CG touch my Abacus!
When you're wrestling a gorilla, you don't stop when you're tired, you stop when the gorilla is.
Cogito ergo thumb - Sucking my thumb helps me to think.
|
|
|
|
|
As an alternative, it also looks a bit like a Query Object - mapping onto a Repository pattern.
|
|
|
|
|
|
I'm thinking condition-based programming. I'm not sure if I just made that up right now though.
Also, isn't that exactly the type of thing you can already do with a Linq query?
It is elegant, just like Linq, and it's a good thing to do as long as you can implement it in such a way that the condition is only executed as little as possible, and you don't have to load the whole potential result set into memory and then filter it.
It's more functional programming than declarative, I think. In languages where functions are first class objects (e.g. Javascript) it is more common to pass filter functions or other types of function (for example a sort order comparator) around and potentially declare them locally as you have done here. What you're passing in the 'where' parameter is a pure function.
|
|
|
|
|
BobJanova wrote: Also, isn't that exactly the type of thing you can already do with a Linq query?
Yes, it's certainly like Linq  The difference is that it may or may not cause a Linq-to-Entities query to run and hit the database server.
BobJanova wrote: It's more functional programming than declarative, I think.
Yes, I suppose it is. I was focused on making it easy to use rather than the programming paradigm.
Thanks,
Nick
|
|
|
|
|
I don't know if it's known or not.
You could call it "Query Mapper"
If your actions inspire others to dream more, learn more, do more and become more, you are a leader." - John Quincy Adams
You must accept one of two basic premises: Either we are alone in the universe, or we are not alone in the universe. And either way, the implications are staggering” - Wernher von Braun
|
|
|
|
|
YAPNBUDP - Yet another pretentiously named but unnecessary design pattern
"If you think it's expensive to hire a professional to do the job, wait until you hire an amateur." Red Adair.
nils illegitimus carborundum
me, me, me
|
|
|
|
|
I use this stuff all the time, and love it !!
Linq, Lamdas, Linq with Lamdas..
It saves a lot of time with EF.
|
|
|
|
|
Baxter R Pearson wrote: It saves a lot of time with EF.
Exactly
I've sent you a PM - could you let me know if it doesn't come through ( sometimes they go missing. )
Nick
|
|
|
|
|
'Specification Pattern' with only one logical chain.
|
|
|
|
|
Isn't it just a simple Facade pattern?
|
|
|
|
|
Nathan Gloyn wrote: Isn't it just a simple Facade pattern?
It does hide a lot of complexity, but I think the difference is that the parameters passed are functions not values.
I don't know if that makes it a different pattern, though
Nick
|
|
|
|
|
From the all knowing Wikipedia:
A facade is an object that provides a simplified interface to a larger body of code, such as a class library. A facade can:
- make a software library easier to use, understand and test, since the facade has convenient methods for common tasks;
- make the library more readable, for the same reason;
Certainly sounds like its a facade based on that definition
|
|
|
|
|
My favourite patterns in order are:
Paisley, spirals and tiger stripes.
|
|
|
|
|
I have been working with a pattern called "composite specification" that uses lambda expressions in this way. We are looking at combining it's use with NHibernate, which can turn the composed lambdas into SQL. Seems like a pretty powerful, flexible approach to me.
|
|
|
|
|
I've sent you a PM - could let me know if it goes missing? ( they sometimes do )
Nick
|
|
|
|
|
How about LOOP?
LINQ-Object Oriented Programming
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
|
when you use lambda expression and delegates, these are a variant of the observer pattern.
|
|
|
|
|
List<user> users = DAL.User.FetchAllUsersOfLegalDrinkingAge();
Then define a static list with all countries and districts with said age.
I hate parameters.
Edit:
(And yes it may be the facade pattern)
modified 20-Oct-19 21:02pm.
|
|
|
|
|
Technically it's a DSL (Domain Specific Language) implemented on top of a formal language. You can tell if it's a DSL if simply reading the words makes approximate sense in English:
User fetch all where the user age is greater than 21.
You could obviously improve it:
Fetch all users where the user age is greater than 21.
var users = Fetch.All.Users( where: user => user.Age > 21 );
The paradigm you are using is very close to a fluent interface - technically fluent interfaces need to happen with method calls (DAL.Users().Where().Age().GreaterThan(21)) but there isn't any reason you can't violate that - especially if it increases clarity (which yours does).
He who asks a question is a fool for five minutes. He who does not ask a question remains a fool forever. [Chineese Proverb]
Jonathan C Dickinson (C# Software Engineer)
|
|
|
|
|
Directed Expression Retrieval Pattern (DERP for short)
|
|
|
|
|
Well, it is declarative. It using Linq and lambda. Call it "dLinda". 
|
|
|
|
|
I think that you are talking about basic coding rules that unfortunately most people don't follow or teach or profess often enough, because they get caught up in making sure they separate everything out in to tiers or MVC or MVVP or whatever other bs is popular atm.
1) If you are going to re-use the logic then create a method to centralize the age check, so you don't have the same thing in 2 places.
2) If you are not going to re-use the logic then put it closest to where it will be used.
I see people all the time create methods in the BL layer to encapsulate the call to the data layer, because someday another developer will browse through and say, hey...look, I already have a method that does that, and it will save them 5 seconds from having to write it themselves or search to see if it exists elsewhere. Put the logic closest to where it will be used unless you KNOW it is likely to be re-used. There are exceptions if you are working on really big applications, but most apps are small, and the added abstraction makes maintenance a beast.
If you want to call it a pattern then please follow the one and only pattern that really matters: Keep It Simple. Abstraction by default is a sign of lack of experience. And those people with 20 years of programming experience on their resume that are itching to post how I got it all wrong (if you are harumphing right now, I mean you). You are idiots that make life difficult for the rest of us. Do us all a favor and go get a job mowing grass or something.
Raymond
|
|
|
|
|
rdalton2100OrSomething wrote: I see people all the time create methods in the BL layer to encapsulate the call to the data layer
And there goes the independence of the business model, rules and entities. If the business layer becomes dependent on the data layer, then it's not just a business layer. If someday they way to fill the business entities change, this will create a nightmare. You also can't share the business objects between applications that have different data sources.
For that we may have a service layer that fill the business layer with data, this way the data layer has no dependency on any layer whatsoever, making it easily consumed by any other layer, architecture or application domain.
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
