Is there an OR/M (object relational mapper) that can be used in Classic ASP? Even a simplified class object would be a great help in handling simple CRUD tasks.
Yes I know ASP.NET has many and I use a few of them for ASP.NET sites. However this is a legacy e-commerce site that uses ASP/VBScript and a total rewrite it not a possibility.
You could use .net through COM Interop, and do your ORM in .net. Another option would be to use Code Smith, or MyGeneration and generate VB6 classes.
Here's some VB6 ORM I have not used or researched any of these:
http://www.sparxsystems.com.au/products/ea/features.html
If I find anymore Ill update
There is nothing stopping you from using C# or VB.Net and COM Interop to create a DLL that could be read by your classic ASP page. We have done that several times.
MSDN has two good tutorials on COM Interop.
Try my project called Clapper. Its available on Github. https://github.com/jeremychild/Clapper
I also created a framework, but not is so strong than some frameworks said above,
is a simple but very useful framework and helped me a lot.
It's here:
https://github.com/FelipeNathan/asp-orm
and it's in portuguese
I think IMVHO that ORM is a good choice for small projects but I prefer the easy and direct ODBC connections for larger ones.
All the (good) features of the ORMs can be provided by good RDBMS like Oracle or SQL Server.
Related
Does anyone know if there are any ORM tools or Code Generation tools that work against an Advantage Database?
It would be helpful to know what development environment you use.
For .net:
Microsoft Entity.NET Framework
Telerik
Developer Express (Express Persistent Objects)
For Delphi:
I believe REM Objects has a framework that works with Advantage too.
Probably yes, but you'll need to write a NHibernate.Driver.IDriver implementation.
Don't worry, it's easy. You can start from any of the most simple ones at https://nhibernate.svn.sourceforge.net/svnroot/nhibernate/trunk/nhibernate/src/NHibernate/Driver/
Also, you should write a NHibernate.Dialect.Dialect implementation, or you'll only be able to use the basic functionality provided by GenericDialect.
Somebody posted C# source for an Advantage Database NHibernate dialect/driver to the nhibernate-development google group; you should be able to use this with any current ADS ADO.NET provider.
However, you should take note of NH-3078 "TimeAsTimeSpanType issue when using Sybase Advantage Database", which doesn't seem to be fixed yet as of now.
I have some friends who are 'old-school' VB6 database developers and I was telling them about .NET and its features, specifically ADO.NET.
In our conversation, they brought up the following reasons why they would rather stick with ADO than move to ADO.NET:
The Dataset is disconnected (What if power fails?)
The same amount of code still has to be written
The new options of Dataset, BindingSource and TableAdapter seem confusing
the same code is written programatically access the Database, all that changes is how that command is laid out
I'm looking for answers or reasons why ADO.NET is 'better' than ADO with regards to data access when it comes to Windows Forms applications. What does ADO.NET provide that ADO does not? What does it do better than ADO?
NB: I'd like examples that do not involve LINQ.
On the one hand, if it ain't broke, don't fix it. But on the other - VB6? Really? Sounds like ADO vs. ADO.NET is small potatoes here...
I think the issue is more VB vs. VB.NET and then the whole code-base, skill-set, other-non-technical-considerations come into play here.
ADO is unsupported COM-based technology. VB 6.0 is end of life unsupported technology as of March 2008. DAO, RDO, ADO are all technologies that are nearly a decade past their prime.
ADO.NET is a modern toolset for data access. In particular, LINQ to SQL and the Entity Framework take data access to new heights.
There's nothing wrong with using ADO in legacy VB6 applications. And if these applications are functioning correctly there's no reason to change them.
I don't think anyone programming in .Net will be too tempted to try to use ADO since it feels like such a hack job when you try to. Just let them be.
Simple answer: don't convince them...
Have them look at LINQ to SQL (or better yet LINQ to Entities)
One of the biggest issues that was able to get people to switch to ADO.NET at my day job was the fact that ADO (VB6 flavor) is all COM, you get better performance with ADO.NET.
I'm guessing if the recordset is still connected and the power goes out on the server, the user would get prompted immediately in their app before they continue to enter data that won't get saved?
How about memory garbage collection?
Distributing updates is easier in .net.
I guess if you have a lot of code in VB 6 for winform apps why change? Maybe if you start a new project using VB.NET you can show some other benefits like including multiple tables in a table adapter (Can't say I've taken advantage of that).
I prefer ADO.NET myself, but just for balance, there is one advantage of classic ADO over ADO.NET: it is arguably more usable.
Our customers found it difficult to
use [ADO.NET] because of the extensive
initialisation it requires. Even in
the simplest scenarios, users are
expected to understand complex
interactions and dependencies between
several types... Note that many of these
problems were addressed in the .NET
framework 2.0.
Written by the architects of the .NET framework, in the .NET Framework Design Guidelines 2nd Edition page 25.
Forgive me if this is a repeat question. I've searched StackOverflow and did not find the answer to my question, so here goes.
We currently have a web application running ASP.NET 2.0 with AJAX Extensions 1.0 and SQL Server 2005 running, is deployed on IIS 6 and developing in VS2005. All works great, but I'm trying to find compelling reasons to migrate. The clients we serve to do not permit plugins in general in browsers, so Silverlight is not a reason for us to migrate. Also, we don't have any plans to migrate to SQL Server 2008 any time soon and ASP.NET MVC is not in the works either.
Here's my reasons to migrate. I would like people to comment on them or add to the list:
I want to work with the newer .NET stuff (and I think other developers would too. Also appealing to prospective employees)
Want to keep the technology up to date.
Extension methods
PageMethods in WebControls
WCF
LINQ maybe (we currently use AutoSproc for our DAL)
ASP.NET AJAX built-in to ASP.NET 3.5 (not really a big deal though)
VS.NET 2008 JavaScript Intellisense
My favorite parts are:
Lambda expressions
Functions available in the
System.Data.Linq namespace:
Where(...), OrderBy(...),
ForEach(...)
Extension methods (add a "ToDelimitedString(...)" to all IEnumerable!)
Visual Studio 2008 is nicer with
HTML/web syntax and debugging,
including the aforementioned
Javascript intellisense and
debugging.
Each of these allow you to write code in a more productive manner.
It largely eliminates the boilerplate "foreach", "if x != null", and other boring constructs.
The javascript intellisense is a huge improvement over anything that's come before. But at the same time it still fails in some very spectacular ways. All in all a good step but not something I've been able to use as much as I'd like.
The extension methods and linq (linq to objects and lambdas, not just linq to sql) are very cool, but since you have an orm already set up you won't use them as much as you'd like either.
WCF is okay, but you're probably not going to re-write your existing services for it.
I think the biggest reason up there is keeping your employees happy and attracting good new ones.
You have absolutely no reason to upgrade, from a business prospective.
You have absolutely every reason to upgrade, from a developer prospective.
Just keep in mind that SQL 2008 is not backwards compatible with SQL 2005, meaning, if you develop something in SQL 2008, chances are, your 2005 platform will barf at it. I just recently experienced this with SSIS packages.
LINQ is a reason to upgrade, even if you don't swap out your DAL, or don't do it for a while. In the product I've been working on lately, our development schedule is such that there's no room to change our DAL to a LINQ-based one for a while yet, but even so I find good reasons to use LINQ-to-Objects and/or LINQ-to-XML in probably 60% of the classes I touch, and I love it.
Everything still runs on .NET 2.0, it's just library and language enhancements and an improved IDE experience, which are made to increase productivity. Increased productivity = justification.
I use LINQ all the time now, every single day. It's not just for your DAL. It's about querying anything, with the same API over top. More generally, lamba expressions provide you with the ability to do some things that are very complicated and take a lot more code without them. Anonymous types are very useful as well.
All the points mentioned are valid.
But as a developer, when facing this kind of question, I always ask myself from the other side.
What is Compelling Reasons NOT to Migrate from ASP.NET 2.0 to ASP.NET 3.5? I find it easier to get myself motivated to upgrade.
The free Microsoft ASP.net Chart control and the new version of Ajax tool kit both require 3.5. If i'm not mistaken.
Has anyone used this ORM?
Telerik OpenAccess
Critiques/Praise? I work in an office that is heavily invested in other telerik venues and I would like to know more about their newest product and whether or not it should be avoided.
I'm testing it, the free Express version.
Pros
Performance (caching, lazy load etc. out of the box)
Easy integration
Great VS.NET integration, wizards
Cool community
Cons
Missing real distributed architecture support and patterns
Wizards hide configuration files and sometimes you must fix thing with hand
SQL CE support still missing
Chris is right, but Entity Framework works like beta, and OA has LINQ support too.
Personally, I think .net's Linq and it's entity framework are the best since sliced bread. I also use telerik a lot and look into everything that they make but ORM doesn't compare to M$ .NET Linq.
Chris
Microsoft Ajax Library has added full object orientation to JavaScript. Is there any library, framework, component, package, etc equivalent for T-SQL? It would be very nice to write object oriented SQL scripts in MS SQL Server.
Cheers,
afsharm
SQL Server, like other RDBMSs, doesn't come in an object flavor. Sorry.
These days this problem is solved on the application end through the use of ORM (object-relational mapping) frameworks. Options depend on what development platform you're using. For .NET, take a look at Microsoft's Entity Framework and SubSonic.
Closest thing I can think of is SQL CLR.
Otherwise there is no OO scripting support in MSSQL.
LINQ - kind of...