One simple request... So many options!!!

One simple request... So many options!!!

  
Hey all!

I have a very, very simple request for my application that I could resolve in four different ways and I can't decide which is better... So I'm going to ask your help!

The idea is simple, I have some screens, and the client wants to be able to change the text of those screens and he doesn't care how! He just doesn't want to republish the application every time he wants to change a text... Ok, so here are my options:
  • Site Properties: I know this starts to smell like Site Properties would be the way to go! But I need at least four of this lists for different purpouses, one for messages, other for errors, etc... So, Site Properties seem kind of unorganized to create this different lists.
  • Language File: Hmmm.. Another way to tackle this would be with a .resx that contained all my strings and that was easly changed... But it seems kind of a major misuse of .resx files!
  • Entity: Ok, this is the most common method. It is dynamic by definition, it is stored in the Database (Yes, the client doesn't care if he has to change the values directlly in the Database) but it seems kind of heavy to such a regular operation... This would mean a call to the SQL every time a Web Screen is called, but maybe it is the better way to do this.
  • Static Entity: Interesting... But here I have a major doubt: Would the client be able to change it's values directlly in the database? If he is, I believe this would be an interesting approach...
So, this is my doubt, maybe the answer to this is obvious and I swear I will whip my back several times if this isn't even a question.. But I got confused. We have no time to make a backoffice and the client really needs to be able to change those values.

Thank you for your time,
Pedro Magalhães



Hi Pedro,

Thank you for your post, since this could be a common question for many people.

From the 4 alternatives you pose, I suggest having something like a Content Management System works. You create a back-office application so that your client can change the entity's values and save them (I mean, he is not going to write SQL update scripts, nor is he going to change the database by hand ;) ). In the webscreen you fetch the content and render it.

The .resX file doesn't really seem practical - you're not going to have your client messing with the .resX file directly, and probably incorporating such a read/write functionality wouldn't be worth the trouble.

As for static entities, they are also stored in the database, so there isn't much advantage versus the entities - at least at first sight. Furthemore, unless he's going to mess with the DB directly, he'd have to publish the eSpace again - and change the values in the eSpace, which really doesn't seem practical.

About site properties... Well, they are also stored in the database, so I'm not convinced that they would be the best solution. The only advantage is that they're cached... But once again, for them to be changed, your client would have to have access to Service Center.

All in all, the decision between site properties and a generic entity in the database should boil down to the amount of updates that they're going to get, and what your client actually wants to do.  But I'd say that 99% of the times you should go for a specific entity and create a backoffice screen for the client to update it. As for the query performance - if that ends up being a concern - you can always optimize queries, and create indexes in the database table if necessary.

After all, this page you're seeing now has content from tons of different database tables - each post is in an entity, the top menus values are stored in entities as well, the user pictures, the user statistics, almost everything here is dynamic, and the database handles these requests pretty well.

Hope this helped!

Regards, and let us know how it went.

Paulo Tavares