1.      Get the data model right

As the sole input to Designer, it’s perhaps obvious that getting the data model right before you start is going to help you.  But, and it’s a big but, we really can’t stress enough that every minute you spend ensuring that your data model is correct could save you hours of development time.  In fact, it is so key to successfully building an application that we were going to make it tip number two (and three) as well.  Don’t rush your design, and don’t rush to move into Designer to start generating. 

If in any doubt about your data model, check it.  And then check it again.

2.      Name tables and columns meaningfully

Designer uses the table and column names within your database schema as literals on pages in your generated application, so it makes a lot of sense to name your tables and columns appropriately and meaningfully.  On top of which, it can help you in the long run too because you’ll have less need to create a data dictionary or document your schema.  And if you’re planning to do lots of code customisation, you can always switch to Visual Studio and use Intellisense to type in the long names for you.

3.      Favour coding efficiency over normalisation

There are definitely scenarios in application development where placing greater importance on the ease of development than the principle of normalisation is sensible.  Over normalising your database, purely to adhere to the principles of normalisation, can result in messy, complicated code requirements which Designer can’t generate for you and which are time consuming to write and expensive to test.  When confronted with the choice between normalising for the sake of it and sticking to simple, generated code, we opt for the latter.

 If you’re a database purist, you’ll disagree.  But I guarantee we’ll build our app quicker than you will and I’ll bet it has fewer bugs than yours too.

4.      Use lookups

Some people find the idea of creating separate lookup tables for every field in your application time consuming, monotonous and over-engineered.  This can certainly seem the case when building a schema for an application with a large number of fields which will require lookups.  Faced with this scenario, you may be tempted to create a single lookup table, with an additional column specifying the type or nature of the lookup value.  You’ll consider then simply filtering the values displayed in the lookup for particular fields.  Look, you’ll say, my data model is now much smaller!  How clever, you’ll think!  Until you start trying to override the populate methods of every single dropdown in the application.

Considering using a single lookup table as above?  Well, don’t.  You’ll thank us in the end, we promise you.

5.      Reuse the application generator

We frequently find that users are unaware that the application generator can be used again after the first generation of the application.  Well, it can, and it’s something that we would recommend you do on a regular basis.  By reusing the application generator, and changing the generation options in each case, you can fine tune each generated page to your requirements at the click of a button.  Run through the pages your app requires and identify pages which have similar design requirements.  Then fine tune your generation options and run an iteration of the generator for each group of pages.  Less manual customisation to do at a stroke.

6.      Use database literals

We’ve already suggested naming your tables and columns meaningfully.  But sometimes it just isn’t possible to name a column exactly as you’d like it appear on your pages.  That’s when you need to move into the Databases tab within Designer and make your changes.  It’s often tempting to override the names of columns on a page in the presentation layer but we would strongly advise against it.  Make your changes in the Databases tab and you’ve made them across your entire application.  Make them on a page and you’ve only made them on that page.  And, what’s worse, is that even if you then change them in the Databases tab, Designer will consider your page-level change as more important and not override it.

7.      Use the formulas tab

The formulas tab is a key tool to take with you on your route to successful app development.  This is true if you’re comparatively new to the product and hesitant to get stuck into the code.  But it’s also true if you’re a seasoned developer who is entirely comfortable with coding.  Simply put, the functionality provided by the formulas tab can be included in your app quicker than you can type it and is less likely to have bugs.  Designer will just make life easier for you, such as automatically handling postbacks if required. 

8.      The code customisation wizard (CCW)

We’ve all encountered complex or unusual user requirements and sometimes there is no avoiding having to use code to get the job done.  However, even then, don’t forget to look for a code customisation which might give you a head start.  It’s unlikely that you’ll find a code customisation in the wizard which is exactly what you need.  But, if you find something close (and more often than not, you will) then a good chunk of the work is already done for you.  Even if all it does for you is confirm that you’re thinking about tackling it in the right way, it’s worth it.  Check the CCW first.

9.      Use ASCX controls

Spending some time customising a layout?  Think you might ever need to use it again?  Then build it as an ASCX control and include it on the page rather than building it directly onto the page.  ASCX controls are an integral part of Designer but they are commonly overlooked because, in most cases, Designer doesn’t automatically generate them.  Building an ASCX control in Designer is just as easy as building an ASPX page.  But unlike an ASPX page, you can reuse them anywhere.  You can even reuse them in other ASCX controls.

Once you realise how much time you can save by using ASCX controls you’ll use them everywhere. 

10.     Embrace the product.  Work with it and not against it.

Were you a DBA before you came to use Designer?  If you were then the chances are that you’ll approach developing your app from the database perspective and try to solve all your challenges with triggers and custom stored procedures. 

Were you a developer?  Yes?  Then you might try and code your way through your app development, thinking less about what Designer could generate for you.

Whatever your background, we’d recommend that you try to forget some of your past experience when using Designer.  When you fully understand all that the product can do for you, you’ll find that you design your applications to suit it; leveraging the power of code generation as far as possible before working on customisation.