Any body using NHibernate? So far I like it, but it honestly doesn't feel stable. When running tests, sometimes (sometimes!) the queries that ran fine just before bomb out with
Message: expected in: <end-of-text>
The query executed was "from prf_ProfileSection"... not much else to screw up here, yet the parser fails. Then, I recompile the DLLs and run and it works again...
Anyhow, the main question for this blog post is what's your favorite OR/M and how flexible and stable is it?
So now I'm faced with a change that I realize can't be applied... but I really don't want to restart! Reasons are that to get to this point, I had to step through a lot of code line by line, and I needed to make one slight adjustment... and I want to save that adjustment, but continue debugging.
I'm surprised many others haven't been annoyed by this...
Register your view on this feedback item:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=110163
Counting the days (til when??) that I will be able to get my hands on the new Beta 2 bits of VS Orcas.
I look forward to actually being able to use LINQ, the split view for ASP.Net designing, and a few other things... Initializers, lambda's, etc.
...Are spitting out invalid markup... For instance, nhibernate's schema has moved to a version 2.2. whereas CodeSmith's NHibernate templates are still spitting out 2.0...
Anybody worked with them?
After reading this post about LINQ, I think a few people are missing the point of LINQ... LINQ *replaces* any "Data Access layers" that have been created.
When you build methods in your data access layer, like "GetCustomersByCity," you're actually creating a wierd separation between the data and business layers. In a sense, you're defining business logic in your data layer. The important thing to remember, is that your business layer RELIES on the data layer to retrieve and persist entities so the business layer can process them.
LINQ's future
I see the future where LINQ augments our current Data Access layers and eventually most of the hand written code (call into very specificly created stored procedures for data optimization) will become obsolete.
Moving forward, a project would simply use SqlMetal (or any other code-gen engine for that matter) and build the Linq-supporting types into your current Data Access layer. Then, when you add new business logic components, and upgrade existing business logic code, add the newer LINQ-style access into the business layer.
Eventually, you'll find that most of the data access handling will be through the LINQ-execution engine, and less and less custom developed code.
Performance
Of course, there's always a case where a specific method is written to short-circuit some code path for maximum speed... Those particular instances may be better, but frankly, to quote ScottGu's post on LINQ: "LINQ is fast... very fast"
Some other articles about performance with LINQ:
- blogs.msdn.com/mattwar/archive/2007/07/05/linq-to-sql-rico-drops-the-other-shoe.aspx
More to come...
ScottGu has been busy writing some articles about some of the new features contained in the new Beta 2 bits of Visual Studio "Orcas":
- Part 1: Introduction to LINQ to SQL
- Part 2: Defining our Data Model Classes
- Part 3: Querying our Database
- Part 4: Updating our Database
- Part 5: Binding UI using the ASP:LinqDataSource control
So far, its an interesting read... In particular I like the idea of the <asp:LinqDataSource> control, but I'm not so sure the implementation was correct...
At first glance, having a "TableName" property for the control seems counter-intuitive to LINQ, since I question how many times would I only use 1 table...?
However, I'd like to reserve judgement until we get our hands on it and can check out the LinqDataSource control for ourselves.
In the mean time, we all have a lot of cool stuff to look forward to!
When using BoundFIelds and domain objects... BoundFields use some algo that can't traverse the object hierarchy.
What am I talking about? Take for instance a Northwind database, with certain objects mapped to data tables:
public class Customer
{
public int CustomerId;
public IList<Order> Orders;
}
When binding to a list of Orders in a gridview:
int customerId = int.Parse(selCustomer.SelectedValue);
IList<Customer> customersList = CustomerService.GetCustomersWithOrders();
this.GridView1.DataSource = customersList;
this.GridView1.DataBind();
<asp:GridView runat=server id=GridView1>
<Columns>
<asp:BoundField DataField=CustomerId />
<asp:BoundField DataField=Orders.Count /> <!-- CAN'T WORK -->
<asp:TemplateField><ItemTemplate><%# Eval("Orders.Count") %></ItemTemplate></asp:TemplateField> <!-- DOES WORK -->
</Columns>
</GridView>
I keep posing the question to ASP.Net Program Manager ScottGu, but can't seem to get a response. A feedback item was created to address this, yet it seems very low on the priority list.
In all my experience, I cannot understand why such an important feature, needed by anybody using an actual domain model with objects, cannot use BoundFields out-of-the-box. A "workaround" is to use the TemplateField and Eval... but thats just a poor hack. You don't get any SortExpression support. Before ASP.Net AJAX Extensions, you couldn't even use the ClientSide callback framework with GridViews that contain TemplateFields. You'd get an error saying TemplateFields weren't supported... pfft!
This is really disappointing... I'm using NHibernate to do the OR/Mapping and when I pull these fully hydrated objects from NHibernate queries, I still have to find a way to "flatten" the objects before they hit GridViews. LINQ has this ability, but I'm not cleared to use LINQ on this current project.
I say we need to step up the level of discontent with certain features... If enough people complain and validate the problem (via the feedback item) hopefully it'll get fixed in the next 10 years.
In the interim, has anybody recoded BoundFields (perhaps using Mono source code as a template?) to properly evaluate nested Properties on objects?
Has anybody found a decent solution around this problem?
UPDATE: I'm creating a feedback item to re-address this. Link will be here.
http://www.shelleytherepublican.com/2006/07/03/americans-demand-justice-tougher-sentencing-for-hackers.aspx
An article full of disinformation and just downright ignorance on a subject that this blogger has obsolutely no clue about. A co-worker of mine clued me in with the following quotes:
I especially liked these parts:
"Fact File: The most skilled hackers call themselves “Script Kiddies” because they use Linux PHP scripts to do all their hacking. PHP is an obsolete programming language that was based on an ammateur implementation of Microsoft’s ASP”
And
“Possessing hacking tools should be a criminal offense: This should include any software designed to circumvent other computer’s security, plus products with known relations to hacking tools. For example the Linux operating system includes DVDRIP (for pirating DVDs), SSH (for breaking into remote computers), and Telnet (an older remote hacking tool). All of these evil programs should be outlawed.”
These are the kinds of people lobbying our government. I think they should join forces with Ted Stevens.
Tubes damn it!
I'm pretty sure this is a joke, but it trully is scarey that these are the kinds of people that at least place themselves within listening distance to our Senators and Representatives up in Congress...
Oh yeah, warning, there's a mildly disgusting picture of a hacker towards the bottom of the article... maybe turn off image downloading before you look ;-)
I'm posing a question to the community about which one is better, adding lots of keys into the Page.Cache all with the same CacheDependency set to the same file, OR would you think it's better to cache one dictionary or list structure with the single instance of the CacheDependency?
// set lots of keys with same cachedependency file...
Page.Cache.Add(”key1”, key1object, new CacheDependency(”theFile.txt”));
Page.Cache.Add(”key2”, key2object, new CacheDependency(”theFile.txt”));
Page.Cache.Add(”key3”, key3object, new CacheDependency(”theFile.txt”));
Page.Cache.Add(”key4”, key4object, new CacheDependency(”theFile.txt”));
or another way:
// set one single page.cache value with a single cachedependency...
IDictionary myDictionary = new Dictionary();
myDictionary.Add(”myDictionary.key1”, key1object);
myDictionary.Add(”myDictionary.key2”, key2object);
myDictionary.Add(”myDictionary.key3”, key3object);
myDictionary.Add(”myDictionary.key4”, key4object);
Page.Cache.Add(”MyDictionary”,myDictionary,new CacheDependency(”theFile.txt”));
Of course, getting a value from the IDictionary instance is a little more difficult:
IDictionary myDictionary = (IDictionary) Page.Cache[”MyDictionary”];
if(myDictionary==null) ReinitMyDictionary();
object someValue = myDictionary[”key1”];
versus just pulling directly from Page.Cache... (and remember that we still would have to cast to the specific object)
object someValue = (object) Page.Cache[”myDictionary.key1”];
if(someValue==null) { //either it wasn't found, or was removed... here's the big difference between the two implementations
ReinitMyDictionary();
It seems to be a little cleaner to put the IDictionary instance into Page.Cache, then you know for sure if you have to reload the collection, versus the direct Page.Cache method might be a little more efficient but is somewhat less precise as to what to do when you get a null... Obviously you could do an onRemovedCallback handler to ReinitMyDictionary() and somewhat guarantee for the second way that that key just plain wasn't in the list of keys loaded from, say theFile.txt...
The goal of the algorithm is simply to load theFile.txt's key/value pairs, and if the key isnt found, its just ignored.
I'd like your feedback to see what others would do for this... and what the performance implications are... (multiple casts, versus a single one, etc)
Long story short, I rode a river boat cruise about 4 weeks ago, from Amsterdam, through Germany, and ending up in Vienna, Austria. So many people just out having a blast... I didn't even make it into any of the arenas. They actually had free fanfests with freakin huge screens showing the game, it was almost as fun as being there, I think... maybe I'll start a picture blog somehow, and post the pics, i'll have to host it myself, seeing as its about 5GB's... All digital photos and sharp as a 6 megapixel camera takes.
I got home and realized something... I realized I always complain about something here, so here's to changing it around... here's to complimenting...
...Like Dell's new site... I was configuring a new laptop. It's about time to retire my current one... that HD is kinda slow at 5400rpm, and kinda small at 40gb so i'm using the HD as an excuse... whatever...
Anyways, i'm configuring the laptop on Dell's site, and I hit an option to change, and viola... AJAX postback... I wonder if its Atlas?
Man, I'm really looking forward to the new breed of web applications.
So who's idea was it to bump the version number up, eh? vee three? where's the breaking runtime changes?
(I'm hinting that major version number bumps should be because of a breaking change in the runtime...)