If I search for NHibernate Criteria API query examples in internet there are examples that use Restrictions and others use Expression. What are the differences between those two?
For example:
posts = session.CreateCriteria<Post>()
.Add(Expression.Eq("Id", 1))
.List<Post>();
posts = session.CreateCriteria<Post>()
.Add(Restrictions.Eq("Id", 1))
.List<Post>();
I think Restrictions were released in NH2 and is now the favoured way.
According to Resharper whenever I use Expression I get a hint to say Access to a static member of a type via a derived type
Also according to this post by Ayende:-
Prefer to use the Restrictions instead
of the Expression class for defining
Criteria queries.
In the source code for namespace NHibernate.Criterion.Expression is says that "This class is semi-deprecated use Restrictions"
Expression inherits from Restrictions but it is recommended to use Restrictions. Expression is apparently deprecated.
According to Ayende (old post about NH 2.0), documentation will usually refer to Restrictions.
Related
I need to construct objects with many properties.
I could create one constructor with one param for each property:
class Friend{
constructor(name, birthday, phone, address, job, favouriteGame, favouriteBand){
this.name = name;
this.birthday = birthday;
this.phone = phone;
this.address = address;
this.job = job;
this.favouriteGame = favouriteGame;
this.favouriteBand = favouriteBand;
}
}
or I could recieve one param with a literal object or an array with all the values:
class Friend{
constructor(descriptor){
this.name = descriptor.name;
this.birthday = descriptor.birthday;
this.phone = descriptor.phone;
this.address = descriptor.address;
this.job = descriptor.job;
this.favouriteGame = descriptor.favouriteGame;
this.favouriteBand = descriptor.favouriteBand;
}
}
In which case should I use each one?
Is there a design-pattern about this subject?
I'm interested in OOP. I'm using Javascript but it could be wrote in any other language supporting OOP (PHP, Java, C++, Python, any other possible)
The first one seems more explicit for the clients as each parameter is defined in the constructor declaration.
But this way is also error prone as you have many parameters and some parameters have the same type. The client can easily mix them as these are passed to.
So in this specific case, using a literal such as constructor(descriptor){...} seems clearer.
I am not sure that this type of constructor be a design pattern. It is rather a constructor flavor that depends on the requirement but also on the language used.
In JavaScript, it is common enough as it is straighter and it avoids writing boiler plate code for setters method or a builder constructor.
But in other languages as Java, defining a constructor with so many arguments is a also bad smell but using a literal is not a possible alternative either.
So using setters or a builder constructor is generally advised.
If you think about it that many fields in a single object is a slightly annoying pattern. It's not a terribly bad smell--let's call it slightly oderous.
The one case I've seen for having many fields like this is Java Beans or pojos. These tend to be a class with a lot of fields with annotations telling various services how the fields should be used. These don't really need complex constructors because they are usually created using the annotations for guidance.
Other classes--the ones with logic in them--don't usually need this many initialized fields.
When they do need this, I'd lean heavily towards factory pattern & immutability.
Intellij has an add builder pattern refactor that would be good for this, there is probably one for eclipse/netbeans as a plugin but I haven't looked too hard for it.
Wow the 3rd edition just came out, but the correct answer for this is you should use Bloch's Static Builder Pattern, which solves both the problem you note here, and the related (maybe more important one) of how to make many of the fields immutable.
Read about it here.
It's not obvious to me from reading the current API design guideline, which of the following version is better.
class MediaLoader {}
class MediaRequest {}
let mediaLoader = MediaLoader()
let mediaRequest = MediaRequest()
// Option 1
mediaLoader.add(request: mediaRequest)
// Option 2
mediaLoader.add(mediaRequest: mediaRequest)
// Option 3
mediaLoader.addRequest(mediaRequest)
// Option 4
mediaLoader.add(mediaRequest)
Which of the above conforms to the current API design guideline the best?
The answer really depends on the purpose and semantics of MediaLoader. If MediaLoader is only a collection of mediaRequests, then .add(mediaRequest) is the way to go because it would flow grammatically and be meaningful in context.
On the other hand, if a mediaRequest is merely one of many different things contributing to its purpose, then .add() alone would not convey enough context to properly read the statement. For example, if you could also add display channels or filters, then merely saying .add(something) would not be clear enough. This is when you would use an extended name that describes the relationship. e.g. .addRequest(), addChannel(), addFilter().
But not .add(request:...), because, using a name for the first parameter is not the ideal way to distinguish between relationships. It should be used instead to clarify the method by which the addition will be performed or the way the request will be accessed. This will leave the "nameless" variant for the most frequent and straightforward use case. e.g. .add(fromTemplate:webRequesTemplate) or .addRequest(fromTemplate:webTemplate).
I have two questions regarding Lucene 4.0:
1) I would like to change sorting in Lucene, so I created my own tfidf class and then called TermStats constructor
ts[t] = new TermStats( contents[t].field,contents[t].termtext, contents[t].docFreq, tfidf);
but the message is
TermStats(String,BytesRef,int,long) is not public in TermStats; cannot be accessed from outside package
Does anybody know, whether I really do not have a way to change it?
2) Does Lucene, indeed, calculate tf*idf or just term frequency (tf)? I am asking because I have read about just term frequency but the contructor accepts docFreq which is related with idf.
Any help is appreciated.
Thank you in advance.
1 - Generally, you would rely on Lucene to pass TermStatistics objects into the computeWeight method of your custom Similarity implementation, rather than constructing them yourself.
If you need to acquire them directly, you could accomplish that by calling IndexSearcher.termStatistics (you'll need to pass in the appropriate TermContext to that call, created using the static method TermContext.build).
2 - Yes, Lucene's DefaultSimilarity is an implementation of it's TFIDFSimilarity, which, as implied, does factor in idf scoring.
I'm curious to know about rules for grammar-related/english-related naming properties (not about capitalization etc).
What is recomended way to name class property (for public API): DateEnd or EndDate?
DateEnd approach allows to find more easily and group related properties (intellisense & docs):
DateStart, DateEnd ...
But we don't use names like IdTask, TypeProperty. We use TaskId and PropertyType. And the last ones are more grammatically correct.
So why googling shows that both ways used ~ 50/50? microsoft use both in public APIs.
Following convention, and often grammar, is useful in making an API intuitive and memorable.
As you suggest, TaskId is more common than IdTask, so should be preferred.
Grouping related properties is a useful bonus if it doesn't make the property name too obscure.
Using the Exchange Web Services Task element as an example, reminder properties are grouped as they start with "Reminder", for example
ReminderDueBy
ReminderIsSet
In isolation, "HasReminder" might be used, but this can be changed to "ReminderIsSet" to allow grouping, without sacrificing grammar or readability.
Interestingly, this Microsoft example is inconsistent in that most dates are named for example "StartDate", "DueDate", but others don't follow the convention, for example "DateTimeSent" and "DateTimeCreated".
Is it possible to use Morphia in Scala?
Are there any other lightweight ORMs for MongoDB that support scala?
Check out Salat:
https://github.com/novus/salat
Salat uses pickled Scala signatures to serialize and deserialize case classes.
Morphia is just a persistence layer based on mongo-java-driver that uses annotation in a JPA-style for object mapping. It should perfectly work with Scala.
Among the "native" Scala drivers (worth to mention that all of them are also based on mongo-java-driver), Rogue (developed by Foursquare) is the closest ideologically to Morphia (though it doesn't use annotations, which aren't considered to be Scala-idiomatic).
I prefer "Mongo Scala Driver":
https://github.com/osinka/mongo-scala-driver
Morphia is probably much more approachable and has a (much) smoother learning curve, but it's crucial to realize that the static type-safety and auto-completion support Rogue gives you when querying is really one level above Morphia—Morphia is only runtime safe, which they also admit right the beginning of the README.
Compare:
val checkin: Option[Checkin] =
Checkin where (_.venueid eqs id)
and (_.userid eqs mayor.id)
and (_.cheat eqs false)
and (_._id after sixtyDaysAgo)
limit(1).get()
vs
Employee scottsBoss =
ds.find(Employee.class).filter("underlings", scottsKey).get();
If you change any of the field names or query values to be incorrect, you'll get an immediate typing error, whereas Morphia will only throw an exception at runtime.
See http://engineering.foursquare.com/2011/01/21/rogue-a-type-safe-scala-dsl-for-querying-mongodb/