I’ve been working with Entity Framework for about 9 months now and I don’t think I can go back to a data access layer that relies on SQL strings and stored procedures. The benefits of using an ORM (Object Relational Mapper) over using traditional SQL and generic data access objects are overwhelming.

• strongly typed data entities, no looping through arrays with hard-coded column names to retrieve data
• compile errors on critical database changes
• intellisense, code hints and compile warnings
• less code to write in general, especially when casting and joining tables
• more semantic code, easier to read and comprehend
• automatic data class (model) updates from database

I just gave a demo to my coworkers and there was a mixed reaction. Some DBA’s looked a bit nervous. “You can build apps without SQL? But SQL is what I write!  Will this make me irrelevant?” Fear not, gentle DBA. We still need reports, nightly scripts, backup procedures, data migration, triggers, optimization and many other things that require intimate knowledge of database architecture. But we don’t need 3 stored procedures to update every table.  I think this will actually free DBA’s from the more mundane tasks so they can focus on architecture and other concerns.

ORMs are not perfect and they come with their own unique challenges, but they are nonetheless a giant step forward.

The Object Database

Another not-so-new technology that’s been gaining traction is the Object Database. Many experts are saying, why bother mapping objects to relational data tables when you can just save the object directly into the database?  It makes sense and it is quite possible that object databases are easier to use than ORM’s with a relational database. They’re apparently quite efficient at serializing and querying data.

The main anchor keeping this technology from taking off is the need to support legacy systems, and DBA’s who are unfamiliar with or uncertain of object databases. With ORMs, a programmer can evolve their code independently of the database.  Entity Framework just released support for POCO classes, which is a fancy word for regular classes you write yourself. Writing the classes yourself allows some extra freedom, but loses some of the automation that makes the framework cool and easy. One reason this feature was included was to allow developers to ease the ORM into a system that already has classes built, then to slowly replace their old SQL with LINQ.

Either way, ORMs provide a visual editing tool to represent data relations, and a tool will always exist for this purpose.  With Entity Framework, you can actually generate the database from the models you design, so it’s quite likely that there will soon be a “switch” behind the scenes to simply generate an object database instead, and there will be little to no effort for the programmer.  Switching to ORM makes a system more prepared for an upgrade to an object database.  More and more reporting and analysis tools will likely begin to plug in to the ORM directly instead of the database to employ the same benefits.

The Bottom Line

The bottom line is the same. Object databases and ORMs require no SQL writing. I don’t think SQL will simply vanish or that the skill will lose value right away. But it could gradually go the same direction as Regular Expressions. The need to write SQL will become less frequent, and the tools to aid in the process will continue to improve.  Of course an understanding of the SQL language will aid any developer working with an ORM or any other visual tool in much the same way that an understanding of HTML markup aids the use of visual web page design software.

So, no, I don’t see SQL simply going away any time soon. It’s far too entrenched and it will be decades before all legacy systems begin to migrate away. But don’t be surprised if you begin to see job descriptions begin to pop-up requiring knowledge of Entity Framework, NHibernate or other ORM’s.

From their site:

Why can you go online right now and buy any product you want but you can’t do the same for tutors, handymen, dog walkers, or other local services? Thumbtack is changing that.

Thumbtack isn’t like typical local search directories that simply return business listings with ratings and reviews, leaving you no better off than the paper Yellow Pages.

Instead, Thumbtack gives you the ability to vet, contact and book service professionals the moment you find them.

At Thumbtack, we understand that hiring service professionals requires a high degree of trust. This is why we go out of our way to make sure that our community is held to the highest standards and that you have all the tools you need to feel comfortable hiring someone online.

Thumbtack helps you get the job done at the time and place you want, with someone you know you can trust.

One thing we did like when researching thumbtack is that they preform background checks and have user reviews.  However like with any other free service a user should proceed with caution and common sense.

If you are interested in seeing our posting it can be found at:
Web Design, Presentation Design, Branding & Print

We have actually had a lot of success (and a lot of junk) with CraigsList so hopefully we will also be successful with thumbtack.   Only time will tell if anything is actually going to come of our free ad, if thumbtack does prove to be fruitful we’ll be sure to let you know.

Code Issues

reason #1:

You are attempting to access data and the database connection is closed.

ObjectContext is the base class you inherit from when you generate entities from entity framework.  It handles several tasks, most significantly opening and closing the database connection, writing and executing queries.

If you instantiate your ObjectContext in a using block, the connection is closed at the end of that block.

solution:

First off, be aware that retrieving data is a two step process of writing and executing SQL, even though it’s hidden away and often written in one line. Any code that attempts to access the database must be executed within the using block.

If retrieving an IEnumberable with a query, wrap in a .ToList() to force data loading.

For navigation properties of an entity, use Include(), or call entities.Load().   You must check the .IsLoaded property of any navigation property to see if it’s there. You can’t check if the property is null or it may attempt to access the database.

Also note that even within an entity context, you must call .Load() before calling .Clear() to delete navigation properties from the database.  Failing to do so won’t cause an exception but it will fail to delete the data.  Also be aware that calling .Load() on a detached entity will cause the next error…

reason #2:

Your entity is not Attached.

This is just a variation of the previous issue.  If you already have an entity before instantiating your context, they are not associated just because you are in a using block. Therefore, if you attempt to access navigation properties of that entity, you will get this error because the system assumes the entity came from a context which is now closed.

solution:

Call ObjectContext.Attach(entity) before attempting to access the entity navigation properties. Note: calling Attach can cause other errors which I will address in a separate post.

Database Issues

reason #3:

Another reason is missing navigation entities (a.k.a orphan data). This is the most likely cause if the bug only occurs when requesting specific data, or if you step through your code and the bug occurs within a loop, but not on the first iteration.

solution:

Navigation properties are based on foreign keys. If the foreign key points to a row that does not exist, you have an orphan child row. This can occur if the entity is deleted or updated but the foreign key is set to do nothing. Check your data and try setting the FK action to cascade or set to null.

If the navigation property is nullable, you much check if it is null before accessing any property. This sounds like common sense but it is very easy to forget.

Also, check the table mappings of your parent entity.  If your parent entity has any mapping conditions (ex. ‘When ActiveFlag = true ),  any rows that don’t match the condition will be excluded from the data sets gathered by entity framework. They will be treated as if they were deleted from the database. This will essentially make your child rows orphaned data, but without the safety net of the foreign key violation. Be very cautions with exclusionary table mappings on parent rows.

reason #4

edmx file is out of sync with the database.  This issue can occur any time you change a table or column name in the database and forget to update your model. It is even more likely when multiple developers are working off a shared database.

solution:

Open your edmx file.  Right-click anywhere in the white space and select ‘Update Model From Database’. Select ‘validate’ from the same menu. This will find many issues but some will pass through compile and only get caught at run time. If you have made extensive changes to an entity, it’s often easier and safer to simply delete it from the edmx and add it again. This will reset the names of all your properties but it will ensure they match the database names, which is usually the best route for clarity.

Alison Carroll provides life and business coaching services, and we are honored to have the privilege of designing her website and corporate logo.  This website is a product of months of close collaboration between our client, designers and developers and we are all very pleased with the end result.

The site features a blog and utilizes the WordPress content management system with an HTML5 / CSS3 template (so for anyone using an older browser, it’s time to upgrade).

We thank Alison for choosing Mindstorm and for being a great client to work with, and we wish her the best of luck as she embarks on this new business venture!

See the ConfirmIt Showcase for examples of usage and a downloadable source files.

This project was coauthored by yours truly and John Pencola, author of Liquid Language. It’s our way of giving back to the open source community and also a chance to view coding from a different perspective. We tried to anticipate the various scenarios that programmers would use this plugin to make an API that is both simple and flexible.

We are very eager to get feedback on this plugin.  Please try it out and let us know what you think.

Whatever profession you work in, there are experts out there dispensing free advice over the airwaves. Just by tuning in whenever you have a drive or a spare moment, you can stay on top of current trends, learn about new products or techniques, become acquainted with new terminology and concepts, and generally enrich yourself.

Talk the Talk

I went on an interview about a year ago armed with my portfolio of over two dozen websites and applications, along with my extensive work history.  To my chagrin, the interview was not set up for me to present my work. Instead, I was barraged with questions for hours from three developers sitting across from me like the judges on the American Idol outtakes. Several questions went something like this:

“Do you have any experience working with X?”

“Um…I’m not sure. I’ve never heard of X.”

(interviewers glance somewhat skeptical at one another)

“Let me explain. X is the process where you …”

“Oh, ok. I have done that before, I just haven’t heard it called that.”

Doesn’t exactly get them on the edge of their seat at that point. Even though there’s often several ways to do something, people are often taken aback if you haven’t done it their way before, or even if you have but you called it something different.

The point is that podcasts introduce you to new acronyms, terms and phrases which will eventually become part of your language. In software development especially, understanding these terms allows you to explain concepts and converse with your peers more eloquently. The end result is that you sound like you know what you’re doing. You sound like you’ve done it before and you sound more confident. This is useful for interviews, meetings and discussions where you have to sell your ideas.

Memory Hooks

Another great benefit I’ve found is that when I have to learn a new tool or skill, all these hidden memories of a podcast will come flooding back.  Even if I didn’t fully understand what they were talking about, I picked up on bits and pieces. New concepts become much easier to grasp as you’re filling in the blanks instead of starting from scratch. Then, if I re-listen to a podcast after I have experience with the topic of discussion, I get much more out of it the second time.  Most products and techniques are a solution to a problem. If I’ve experienced that problem and had to fix it myself, I may will think “Wow, that would have saved me a lot of time. I’ll try that next time.”

Additionally, I will often hear an idea and begin to brainstorm my own ideas (I may have to pause and backup a show but that’s okay). Listening to a podcast in the morning wakes up your brain and gets you into “work mode” more than, say, Howard Stern. Unless perhaps you’re a professional womens’ mud wrestling referee.

Some Unpaid Advertising

I use the Beyond Pod app on my droid, a $7 investment.  As a developer in the Microsoft space, my current favorite podcasts are .NET Rocks, Hanselminutes, and Herding Code.  I tried Codecast and Alt.Net but did not find them as beneficial.

I sometimes get bored of code casts, so I branched out into some popular casts Stuff To Blow Your Mind and Stuff You Should Know, from howstuffworks.com. Even off topic casts can give you some more interesting conversations, which can allow you to connect with those outside of your area of expertise, like friends and family, your manager, and the owner of your company. Code abstraction patterns don’t make for a great ice breaker.

And of course there are still times when the droning voices aren’t enough to keep me alert in traffic and I just need to rock out. Then I switch to Pandora.

Validation is the act of verifying that data is constrained to certain rules.  The rule could simply be required input, a certain format such as date, or a complex system of logic that combines constraints on several input fields. When a user submits data, a certain amount of validation is helpful.  We’ve all been saved at least once by having to type in our passwords twice when they don’t match.

The question I pose is this: is there a such thing as too much validation? And if so, when does that occur?

To answer that question, we have to take a step back and look at what’s happening. Data submission of any kind is essentially a conversation between two parties: the submitter provides information and the receiver provides feedback.  This could be through a web form, a paper form, or an interview. An interview requires the most time and effort by the interviewing party but offers the highest degree of validation since they can converse freely.  Paper forms remove the interviewer and thus streamline the process, but provide no validation. Invalid data is submitted, caught while being processed, and the form must be fixed or returned for resubmission.  Valid data must still be processed and stored by an administrator of some sort.  This system has worked fine for centuries and still does, but now we have the web, which brings me full circle.

Web forms can provide instant feedback and force a user to fix errors through validation. This completely cuts out the interviewer and the administrator. It also saves time for the user during entry and shortens the processing time, which benefits everyone. The only cost to the enterprise is that they now need programmers, database administrators and the technical baggage to keep the system running. Still, this is generally a fraction of the cost for the provided return.

Validation is useful for streamlining a conversation for both parties. But once validation starts to hinder the conversation, it’s usefulness declines.

The most obvious occurrence is when validation throws false complaints. This can occur when the rules change but the code logic becomes out of date. Some examples might be the 9 digit zip code or new email formats (I once forgot to allow for European email formats).  These are the simple fixes. The gray area concerns the things I mentioned at the beginning.

The issue is relevant to me not only because I code lots of forms with massive amounts of validation checks, but also because I am currently co-authoring a jQuery plugin to precede user actions with a confirmation dialog to force the user to verify their intent before committing the action. Like validation, a confirmation prompt can protect users from making mistakes, but it could also become a nuisance if it is overused. Since this is a plugin, it will be up to the consumers to decide when and how often to implement it, but to make it as useful as possible, we want the default behavior to mimic the majority of use cases.

And determining  default behavior requires a bit of prediction at this phase. Hopefully, once we go live, we will get some useful feedback from the community and see how close our predictions are.

• Required
• StringLength
• Range
• DataType
• RegularExpression

And the display attributes would be

• DisplayName
• DisplayFormat
• UIHint

The awesome thing about MVC.NET is that simply by applying these attributes, you instantly get server-side validation. And with a few extra javascript includes, you get client-side validation with no custom javascript!

Each validation message has an optional error message that appears to the right of the invalid field along with an optional summary at the top of the page.

Rethinking nTier Applications

At first I winced at some of the display attributes because they are ultimately writing HTML from the data layer, which seems like a violation of tier separation since html is part of the display layer. But looking at the simplicity, reuse and consistency this system provides, it just makes sense.

Employing convention over configuration, the data layer can set many overridable features that would traditionally be considered business layer or display layer. Likewise, the business layer can override the data layer with more specific display names if the model is used by several business layer. The display layer could do the same. The nice thing is that 90% of the time, default values don’t need to be overridden.

Example:
You have  a User entity with a Name property.
Your data layer might provide a display name of “User Name”. This value appears in the label next to the input on the page.

Lets say you have business objects called Employee and Supervisor, which inherits from User.  Supervisor may wish to override this display name as “Supervisor Name” but Employee might just want to go with the default.  Additionally, you might have 50 pages which use various combinations of Employee and Supervisor that could override these display names as needed.

You might be asking, what’s the point? Why not always define label text in the html page where it belongs? I felt the same way, but html pages are generally not reusable, so you may end up repeating the word “Supervisor” 50 times, then your client could ask you to change it to “Manager” (this actually happened). You can do a global find-replace, or just have a few inconsistencies. But in the practical world, the data layer provides a central location for any information that gets repeated throughout your application, allowing more consistency in your Display layer.

Potential IDE Improvements

Because these features are finite and provide predefined options for most of what you need (like a regex for email), I could easily foresee the next iteration of Entity Framework providing a GUI interface to attach these attributes to entity properties in the ORM. In fact, much of this information, such as required, data type and string length, are included in the ORM, but they don’t percolate up to client-side validation. It may have been a design decision on their part or they may have just run out of time.   The point is, I don’t think basic validation is going to be something developers will have to spend much (if any) time coding in the near future.

One thing I’ve learned over the years is that silence is not always golden.  I’m specifically referring to long periods of silence between a client and contractor in the middle of a project.  A former boss once told me he treats client interaction like a tennis game. Just always hit the ball back into their court, he said. Respond promptly to their requests and don’t keep them waiting, even if you can’t provide the solution right away. This is very good advice, people don’t want to wonder if they’ve been forgotten about. And on larger projects where both sides have project managers pushing timelines, meetings and schedules, this system works perfectly fine.

But what about when the line goes dead? What if you, the client, don’t have time to focus on the project you’ve hired us for? Maybe you’re too busy tending to your own clients’ needs or other obligations, or maybe the project just isn’t a big priority. Whatever the case, it’s been my experience that long periods of silence can be extremely detrimental to a project, even if everything else seems fine. Or to use the tennis analogy, you might hit the ball back and not get a response because your client has found a new tennis partner.

Your words, not mine.

Another funny thing happens with memory of conversations over time. We apply our own filters and hear things differently. We sometimes turn implied assumptions into explicit promises, or we omit statements from memory.  A confirmation email is a good basic step to solidify a conversation, but they invariably still leave out details and you just feel icky having to dig through your old emails to set the record straight with a client once a misperception has had too long to incubate.

I once called a client to discuss a delicate matter that I didn’t think could be properly conveyed through an email. The call went well then there was an 8 or 9 month period where they didn’t contact us. We were midway through their site, waiting on content.   Then we got an email out of the blue that our client wanted to go with another firm. They had completely forgotten that we were waiting on them.  I called to repair the damage but it was too late. Time had skewed the memory of the original conversation.  ”I remember you said word for word, ‘bla bla bla’  ”, the client reamed. I had a completely different memory of the conversation and I could see that the client had completely altered the intent of my original call to fit what was in their mind.

Whose turn is it?

One problem with the “only respond to an email” approach is that people forget you’re waiting on them. This often happens for us right after we send a website design to a client for approval. No matter how clear we try to make it that nothing more will happen until the design is signed off, it sometimes fails to register. We may get a non committed answer or no answer at all for months at a time. This happened with a previous client. After waiting several months and making several attempts to get sign off, we received an email asking if the site was finished.

What?  The whole site? Finished? We had received no design approval, no content, not even a site map. We restated that we had been waiting on sign off for months. The client stated that they had approved the design long ago and were very upset with the lack of progress. This time we had our paper trail of emails corroborating our story, but at that point it didn’t much matter. You say the design was approved? Fine. Send along the content and we’ll build your site.

Going in a different direction.

The worst case result of time is that the rest of the world has moved on while you were waiting.  I’ve experienced some of the greatest hits: Company shut down, changing business plan, funding dried up, a competitor beat us to the punch, etc.  See my post on The Perfection Trap for a list of reasons that these cases can happen.  The point is that when it takes several people working  together to get something done, you have to push full steam ahead while the project is on their front burner.

Squeaky Wheel.

Every project is important to us, but there’s simply no avoiding the fact that a responsive, involved client will get more attention than one who’s wandered off into the wilderness. Of course there is the other extreme. I remember a particularly pushy client who called my Chief Technical Officer’s  (CTO’s) house at 4:00 am to report a bug he found on a prototype demo.  4:00 am.  Because it was that important.

Anyway, the point is that for a project to be successful, a client needs to be involved. Not as involved as the crazy guy in my last story, but you have to be involved.  You can’t pass off your idea and expect it to come to fruition on its own.  You have to cultivate the seed to grow into a crop. We are merely a tool to help facilitate the process.  A hoe will not grow a garden alone. You must use the hoe. Let us be your hoe.

I’m not sure what the exact purpose of the study is, but I think it makes a great metaphor for a tool or application that isn’t quite worth the trouble to use. Oftentimes it’s the very simplest differences that determine whether the cost of learning and using a tool is worth the value that the tool provides.

Example: Team Foundation Server takes a long time to load, loads into a small window inside visual studio, and requires lots of clicks to push things through (Assigned must be saved as Active, THEN as closed). The web version loads faster but I hate that I can’t simply check off a list of bugs and perform a bulk update. Creating a new bug requires me to fill out several fields, and it’s just not worth the trouble for most minor bugs, so I jot them down on a notepad in a meeting then type them into a word doc.

Fogbugz has a beautiful, intuitive interface, you could quickly add bugs and manage bugs with bulk actions.  I would write things down directly in fogbugz. Both work, but it’s a quarter on the sidewalk. Granted, I didn’t set it up, and the fact that TFS is built into Visual Studio gives it more credence, and it does have a lot of integrated features which give it more value.

Another example, I just recommended to my collegue and fellow blogger to change his homepage settings to show full articles instead of summaries. this was my case:  my wife reads lots of blogs. She uses an agregate service (google reader) and will only read blogs that show up in full because it’s faster to load and more convenient, especially on a smart phone. She won’t even bother subscribing to blogs with a summary setting. That tiny inconvenience of having to click into your site and back to the reader is that little difference between being a penny or a quarter on the sidewalk. That may be a rare and very subjective case.  I could go on about the best cases like credit card purchase streamlining solutions or the worst cases of sites that make you do back flips to perform the simplest task, but I think you get the idea.

So is your solution a penny or a quarter on the sidewalk? (If you won’t bother to pick up a quarter then you are a snob).  Some factors are personal preference, but they all amount to a few universal factors:

1. Speed.
   The king of kings. Take too long to load your pretty pictures and I’m out. Animation? It’d better be quick and fluid. Flash Intro? Skip. It was cool the first time…maybe. I have to create an account before getting basic info? I’m looking at YOU, experts – exchange . com, (purposely not a link). Don’t ask why stackoverflow is crushing you. Myspace vs. Facebook? Enough said. Keep your glitter, give me my news feed.
2. Usability.
   Yes, noble developer, you find your site easy to use and don’t know why everyone else has so much trouble. Well, they don’t live on the web 8 hours a day like you and haven’t been staring at this app for the last six months.  You have to watch people use your site, see how they don’t even notice your glossy icons and how they struggle to perform the simplest tasks, despite your tooltips, FAQ, user guide pdf and captivate animations. Hear how they curse at your creation, and wistfully compare your solution to their old, dependable paper system.
   Coupled with basic understanding is the general ease of use factor. Forcing users to click through extra pages to get details or update individual records when using AJAX to load extra data or including a bulk update feature would work; these are the subtle features that greatly affect user experience. In instances where users are making an online purchase, they can often make or break a sale.
3. Reliability.
   A.K.A. Quality of Service. “The network is down!” Cries Chicken little. This app has gotten really slow, it’s really frustrating! Oh, that’s because of that sleek javascript thing you wrote. It worked so well in your development environment with two test records. Bet you didn’t account for people pasting 10 page word docs into the “Remarks” field and uploading giant uncompressed powerpoint files.
4. Design.
   This is often the first lamb to the slaughter when budgets or schedules get crunched and that is a great tragedy. A high quality interface design not only provides clarity and improves usability, but on an almost subconscious level, you just feel better when you’re interacting with a sleek, modern design . It gives an impression that the underlying technology is built with the same attention to detail. It is also important that design decisions are implemented site-wide to make a uniform user experience.

There’s nothing revolutionary here; these are pretty much common sense. What I find amazing is how many developers I’ve met that simply don’t seem to care about user experience.  They simply go through their requirements checklist and feel like their work is done when they are capable of executing the required actions within their own application.  The apathy epidemic is most acute on internal applications, partly due to the fact that the audience is a captive audience. It’s their job to use the in-house app and there’s no alternative. Developers can’t take all the blame though. Business decisions often place user experience as a lower priority and don’t allocate the time or personnel required to truly make a project shine.  In many cases, developers aren’t even allowed to add or improve features that weren’t specifically requested or paid for by the client. But in those cases, it’s the client’s fault, and there is no more literal example of the phrase “You get what you pay for”.