One More Feature, One More Table, Now what?

Okay, here is scenario (i duno if it is out there on Forum, if so then please provide me the link).

The client asked for new feature, and it is when we done all the development and stuff using the .NetTier!

So how the .NetTier Template will help me to produce the new layers and classes for newly added Table in my DB?

Thanks,

Mudassir 

Make a backup of your project, since it's not my project i don't know your environment. 

Now you open up NetTiers again in CodeSmith, add that new table to your SourceTables Property, along with all the other tables that were included the first time, and generate right on top of your project.

As long as you didn't change any of the generated code, then you should be set.

That kind of "sucks" feature of .NetTier?

 Isn't it?

Let say if it is the "very huge" project then?

Well it is I think is not the "best practicse" after all?

Take Care,

Mudassir
 

Actually, no, it doesn't suck.  The reason you require all of the tables is because any added, or removed table could affect any number of relationships that the new or removed tables had.  You can't know those relationships unless you include that table in your generated set of tables.

But isn't hte .NetTier's CST file should be that smart that they figure d the relationship and regen all those files which are "modified" ?

 

No, because the only way to do it would be to know which tables you wanted to even care about in your project.  Large DB's can have lots of data warehouse tables that you might not want to generate against. 

Or a better example are the ASPNET_ tables with membership, profile, etc.

 They are in your database, but it's likely that you don't want to include them because you already have a default provider for those tables through ASPNET.  It's also likely that you will reference the ASPNET_Users table in some of your templates.  So that relationship exists, but you don't want to generate that relationship as part of your domain in your project.

 So there's no way to be "smart" enough to know that you don't want that relationship on the next generation if you added a table that references that ASPNET_Users table.  We would add a reference, but then there wouldn't be an ASPNET_Users entity, and the build would break.

It's not like we haven't thought this through.
 

Codesmith and .NetTiers is an exceptionally useful combination / framework... but it cannot replace the intelligence of the person who uses it. What Robert has suggested IS good practice... test out the generation to a new Solution first, to see if there are implications for existing aspects of your code (personally I do this every time - it helps to hightlight any generation errors due to lack of primary keys, reserved words as column names etc), then, generate to incorporate your new table into your existing Solution.

In my team we do this on a regular basis, as using 'Agile' (for that read 'users dont have to think about what they want until the last minute, ) development we have a constantly changing database to accomodate user input. Thats just life. Thankfully we dont have to hand code everything - we have the combination of code generation followed by customisation.