Posted by
Scott
on
17. November 2008 21:48
In a world of Microsoft and third party applications, out comes t4. t4 is a code generation tool that can compete with CodeSmith, but its FREE and built right into Visual Studio. It has been years since the first edition with very little publication of the actual application. t4 is a free code generation engine from Microsoft that underpins the Domain Specific Languages and Software Factory toolkits. t4 is a rich code generation and has the ability to stand up against and compete with CodeSmith. I have used both Codesmith and MyGeneration a lot in the past few years, so I have seen the competition. What is nice about this old/non publicized tool is that it is built directly into Visual Studio 2008.
t4 is being spear headed into the open source market for free templates by Oleg Sych. It brings a long a toolbox which can also be download with extra templates along with a GREAT T4 Editor which of course is also free. There is not more need to spend money on CodeSmith, when Microsoft will do it right out of the box with Visual Studio.
Some have speculated, why hasn't Microsoft published this tool to a greater extent. We can only think that it has to do with being a Gold Partner. Microsoft doesn't like to lose Gold Partners and therefore hasn't truly publicized this tool. The next question you have to ask your self is what can be generated?
- Site Maps.
- Database schemas.
- Session Variables.
- Store Procedures.
- Text Documents.
As of October 2008, t4 Editor has been officially placed as a plug in to Visual Studio 2010, which will boost the ability to generate t4 code through other means besides CodeSmith.
Demos and Other information can be found below.
Point of concern: If your company currently uses CodeSmith, wouldn't it be nice to tell your boss what you found could save the company a few hundred dollars by using something that is already built into Visual Studio? So why not give it a try and save a little money doing it?
If you liked this post, please be sure to subscribe to my
RSS Feed.
Posted by
Scott
on
20. October 2008 16:22
When life throws you hard balls, you can either step back
and take a swing or bunt the hell out of it. I just recently went to an
information session on T-SQL, Stored Procedures and now LINQ. These folks
discussed stored procedures and why they are so important in the world today.
They stated ideas such as:
- Stored
Procedures optimize queries.
- They
stop SQL Injection attacks.
- Stored
procedures are concrete and cannot be changed.
I wanted to briefly state a
counter argument against stored procedures and for T-SQL and LINQ:
- Stored
procedures do not optimize queries.
- A
SP is not an optimized query, it does not save time. SP’s used to save time and have been faster in
the past, but more and more RAD development has been done without SP’s. The development has caught up with SP’s and dynamic SQL has now caught up and in some cases surpassed SP’s. These days
parameterized queries are now cached just like SP’swhich put them on an even playing field.
- Microsoft
LINQ and ADO
teams both admit that SP’s are not faster
than dynamic SQL.
- Benchmarks
have also been completed which explicitly show SP's
are slower over small queries and tie dynamic queries over larger ones.
- Stored
procedures do stop injection attacks, but you can also do it with
parameterized queries.
- SP’s are good at this, but it can also be done
with parameters. Putting a value into a parameter means that it
will not be a part SQL query string at all.
- Stored
procedures are very concrete and are hard to change as a developer with a
DBA. This is the problem.
- As
a developer when you push a product out the door, you want to be fast at
this. Developers don’t want to learn two languages in order
for their product to be pushed out the door and then go back to the
database every time code needs to be changed. They want dynamic
abilities. When SP’s are hard to
change, it might be a bit harder and take longer when you have a
DBA. The inability for SP’s to be
changed or created fast is the issue with this kind of development.
- SP’s mangle the three tier
architecture designed for apps.
- Instead
of having a structure which separates logic from storage, you have
storage and logic on the same tier. This will cause potential
problems down the road.
- Business
logic in a SP does not scale. Business logic should be in code and
not in the storage center.
- When
you have multiple database servers, it is more difficult to keep the
triggers and SP’s synced.
- There
is no Version Control for SP’s.
- In
a place that can be disastrous if you screw up, it should have something.
This is one big reason why people like to avoid SP’s
like the plague. They run away and never move back into town.
If you see the new technologies coming
out of Microsoft now, there will be no need for SP’s
in the future. LINQ is taking care of most of this by allowing for a data
layer cheaply and efficiently with very little effort by the developer. LINQ
handles all these problems and if you truly like a confirmation on all the
things I said, just search the internet for Stored Procedures v.s. Dynamic SQL.
The debate these days has two
sides. Not “Republican or Democrat”, but “Progressive and
Non-Progressive”. The Progressive folks are not using Stored
Procedures these days.
If you liked this post, please be sure to subscribe to my
RSS Feed.