Justification for Upgrade

Posts   
 
    
bshuman
User
Posts: 24
Joined: 14-Dec-2004
# Posted on: 22-Feb-2007 19:00:26   

I am trying to justify upgrading to the current version. We are using 1.0.2005.1 with VS2003 and the .NET 1.1 framework. We are upgrading our app to VS2005. We could continue to use the LLBLGen version we have at no additional cost. To upgrade would cost us $954. Any suggestions on why we should do this and what I can tell my manager?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 22-Feb-2007 19:10:03   

Let me quote the highlights of the new features of v2.0:

Full .NET 2.0 support in generated code and runtime libraries with separate runtime libraries codebase for .NET 2.0, using .NET specific features like generics internally as well for optimal performance.

SqlServer 2005 server side paging queries now use a CTE based query instead of a temptable based query for optimal performance.

Support for nullable types for value-type based entity and view fields. (.NET 2.0 targeting code only)

Support for System.Transactions transactions when applicable (SqlServer 2005, .NET 2.0)

Support for wsdl schema interpretation logic to have wsdl.exe generate typed stubs for webservices instead of DataSet based stubs (.NET 2.0 targeting code only)

New feature-rich validation framework.

Powerful data-projection framework: project any entitycollection or resultset retrieved from a datareader onto any datastructure of any type using generic code.

Ability to specify scalar queries in expressions, so a subquery inside a selectlist or inside expressions in filters is now possible.

It's now possible to fetch a query as a datareader. This query can be a stored procedure call, or a query created on the fly. This datareader can then be used further, if required, to project the data onto classes like entity classes, datatables or custom classes using the generic data-projection framework. This makes it possible to fetch entities through a stored procedure call with very a few lines of code.

EntityView (SelfServicing) and EntityView2 (Adapter) classes added, which are dataview-style objects for entity collections. They support sorting, and filtering in-memory, data projection onto other entity collections, datatables or custom classes. Filtering and sorting is done through strongly-typed, compile-time checked predicate and sortclause objects, which are also used for filters and sorters in database queries.

Expressions now support calls to database functions (UDF's or system functions). Database functions can accept entity fields or normal values you pass to the function or other expressions (like for example scalar queries).

Full support for 2-way declarative databinding and design time databinding in ASP.NET 2.0, using the LLBLGenProDataSource (selfservicing) and LLBLGenProDataSource2 (adapter) controls. These controls support (design time) databinding of entity collections, typed lists and typed views and support server-side paging, sorting and filtering. They also support data persistence / retrieval delegation to different methods (by tracking changes into a UnitofWork object), and filtering/sorting based on parameter binding with other controls on an ASP.NET 2.0 webform.

Full support for design time databinding in .NET 2.0 windows forms.

.NET 2.0/VS.NET 2005: A set of Debugger Visualizers has been added for a lot of classes in the framework to ease debugging your code.

support for CF.NET 2.0 and SqlServerCE 3.0

Oracle support using the Microsoft Oracle provider. This replaces the DataDirect based Oracle support.

SqlServer 2005: support for synonyms for tables and views, support for User Defined Types (UDT) based on CLR classes, support for NEWSEQUENTIALID() so sequential uniqueidentifier values can be generated by the DB and read back into entities.

PostgreSql support for PostgreSql v7.4 and up

Much lower memory footprint of entity collections in memory.

Entity fetch speed has been greatly enhanced.

LLBLGen Pro designer is now running on .NET 2.0, using the new Janus Windows controls v3 for windowing and grids.

Plug-ins can now open their own docked window in the LLBLGen Pro designer

It's now possible to specify in the designer additional namespaces and interfaces to generate into the entity classes

Completely new code generation configuration system, which makes it very easy to add/remove/edit the tasks scheduled in the run queue for code generation.

New template configuration system which makes it very easy to add your own templates to an existing set of templates to enhance or replace existing templates

without having to alter any system configuration.

Much more small enhancements, changes, tweaks and additions.

and of course you'll get the v2.1 upgrade, which is now in development, for free simple_smile

Frans Bouma | Lead developer LLBLGen Pro
jmeckley
User
Posts: 403
Joined: 05-Jul-2006
# Posted on: 22-Feb-2007 20:56:57   

isn't LLBL v1 also locked for feature requests. In other words, any bugs/features won't be fixed/added since a new version exists?

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 22-Feb-2007 21:04:25   

Bugs will still be fixed in 1.0.2005.1, there won't be new features in that version but we still will fix any bug that's popping up unless it's impossible to fix it without breaking anything.

Frans Bouma | Lead developer LLBLGen Pro
BHayat
User
Posts: 18
Joined: 25-Feb-2007
# Posted on: 25-Feb-2007 20:10:30   

bshuman wrote:

I am trying to justify upgrading to the current version. We are using 1.0.2005.1 with VS2003 and the .NET 1.1 framework. We are upgrading our app to VS2005. We could continue to use the LLBLGen version we have at no additional cost. To upgrade would cost us $954. Any suggestions on why we should do this and what I can tell my manager?

Well look at it this way. You want LLBLGen Pro to stay in business. It's just makes sense for your future. Upgrading helps the company stay in business and grow further.

bshuman
User
Posts: 24
Joined: 14-Dec-2004
# Posted on: 27-Feb-2007 19:28:20   

I hope I didn't give the impression that I personally didn't think it was worth upgrading. I am the champion of LLBLGen at my company. Unfortunately, the decision isn't just up to me. That's why I wanted to hear your thoughts about how I could convince my boss that the expense was worth it.

Otis avatar
Otis
LLBLGen Pro Team
Posts: 39614
Joined: 17-Aug-2003
# Posted on: 27-Feb-2007 20:59:11   

If you have more questions or if I need to provide more information, please step forward simple_smile

Frans Bouma | Lead developer LLBLGen Pro
arschr
User
Posts: 893
Joined: 14-Dec-2003
# Posted on: 28-Feb-2007 00:23:08   

convince my boss that the expense was worth it.

Your $900 upgrade cost must be for several programmers, so for each.

I'm costing you $x per hour (say $50). I believe I will increase my productivity by y% by using llblgen v2.0 (say 4%). I get around z productive coding hours per week (say 25 hours). So that effectively gives you an extra hour per week (y times z). 52 weeks times x says payback is q weeks.

Khuzema
User
Posts: 22
Joined: 24-Jul-2006
# Posted on: 28-Feb-2007 12:14:52   

bshuman wrote:

I am the champion of LLBLGen at my company.

It seems to me that you yourself should be able to easily convince your boss (with your experience with LLBL Gen Pro). For me Champion means having Experience meaning Productive.

regards

Khuzema

swallace
User
Posts: 648
Joined: 18-Aug-2003
# Posted on: 28-Feb-2007 19:08:40   

arschr wrote:

convince my boss that the expense was worth it.

Your $900 upgrade cost must be for several programmers, so for each.

I'm costing you $x per hour (say $50). I believe I will increase my productivity by y% by using llblgen v2.0 (say 4%). I get around z productive coding hours per week (say 25 hours). So that effectively gives you an extra hour per week (y times z). 52 weeks times x says payback is q weeks.

Not to mention the savings in server performance. This feature alone made it all worthwhile:

SqlServer 2005 server side paging queries now use a CTE based query instead of a temptable based query for optimal performance.