Is this a known pattern?
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
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'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
How about LOOP? LINQ-Object Oriented Programming
"To alcohol! The cause of, and solution to, all of life's problems" - Homer Simpson
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
when you use lambda expression and delegates, these are a variant of the observer pattern.
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
-
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
-
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
-
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 :)
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
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)
-
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
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
-
Suggestion: Predicated Queries/Query
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.
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
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
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
Sort of falls along the lines of a "fluent interface."
-
You can design any method to use a predicate like that. It isn't rocket science - it's LINQ:
IEnumerable Fetch(Func 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.
-
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
-
When you pronounce it quickly, you can make it sound almost like "PEANUT".
FILETIME to time_t
| FoldWithUs! | sighist | WhoIncludes - Analyzing C++ include file hierarchyHow about "Pin A Mutt"? Kind of like "Pin the tail...", however I'm thinking along the lines of blindfold, crochet(sp?) needle, and a live dog running around. PETA may have a problem with that. :-D PS When I had a dog, I'd never have volunteered him for this "game".
-
I'm having difficulty finding a name for a style of programming. You can make one up if you like, but I'd prefer something that is already documented :) I've written a layer over the Entity Framework that allows the application code to pass parameters into the data layer that shape the returned result sets. So you can write something like this:
List users = DAL.User.FetchAll( where: user => user.Age > 21 );
It's declarative programming, but I was looking for a more specific name. Something like "locality of intent". Basically, you say what you need in the place where you need it. It's the opposite of having a data layer method like this:
List FetchAllUsersWhereAgeGreaterThan( int minimumAge )
Is this a known pattern? I've run out of obvious words to Google. Ta, Nick
Nicholas Butler wrote:
List<User> users = DAL.User.FetchAll( where: user => user.Age > 21 );
This example feels more like a filter to me -- you're accessing the entire list of users filtered through the predicate. So, maybe predicated-filter or predicated-fetch or something like that?
We can program with only 1's, but if all you've got are zeros, you've got nothing.
-
Nicholas Butler wrote:
I just called it caching
Most people do. First law of patterns. They are a fancy name for stuff you already do.
*pre-emptive celebratory nipple tassle jiggle* - Sean Ewington
"Mind bleach! Send me mind bleach!" - Nagy Vilmos
My blog | My articles | MoXAML PowerToys | Mole 2010 - debugging made easier - my favourite utility
Like AJAX, we were doing that "call the server without reloading the page" years before they came up with the name, first using hidden frames, then iFrames and finally XmlHttpRequest!. And Ajax will always remain a cleaning product for me, not a programming thing.
-
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
If you think that there is a significant chance that the data source provider will be changed then it makes sense to create separation. Most of the time this does not happen. We need to stop teaching people that abstraction is the "right" way to write code. It is not. It is the right way to write some code and solve some problems. It adds needless complexity most of the time. Layers are fine if you really share business objects between applications. I would argue that 90%+ of applications out there do not actually do this, so it just makes the code more difficult to change and maintain.