MyGeneration 1.2.0.6 now offers support for Microsoft SQL CE and VistaDB 3.0

If you want a 100% free, very nice Code Generator and ORM mapping tool try the new version of MyGeneration 

You can download it here ....

MyGeneration, Download.com's #1 Development Tool in the .NET Category.

Our next beta will have, among other things, paging built right into the EntitySpaces architecture. The EntitySpaces dynamic query API has two new properties, StartRow and PageSize. Here is a very simple dynamic query that uses these two new properties. This feature will be built into all providers for databases that support some sort of built in paging. The example below uses the EntitySpaces.SqlClientProvider and only works on SQL 2005 as it takes advantage of the new ROW_NUMBER() function in SQL 2005.  

EmployeesCollection coll = new EmployeesCollection();
coll.Query.Select(coll.Query.LastName, coll.Query.FirstName);
coll.Query.OrderBy(coll.Query.LastName, esOrderByDirection.Ascending);
coll.Query.es.StartRow = 25;
coll.Query.es.PageSize = 10;
if(coll.Query.Load())
{
     Console.WriteLine(coll.Query.es.LastQuery);
} 

Notice that we print the Query's LastQuery property. EntitySpaces always provides the raw text back from a query for debugging purposes. Let's take a look at the SQL generated and executed by EntitySpaces. 

WITH [withStatement] AS
(
    SELECT [LastName],[FirstName] , ROW_NUMBER() OVER( ORDER BY [LastName] ASC) AS ESRN FROM [Northwind].[dbo].[Employees]
)
SELECT [LastName],[FirstName] FROM [withStatement] WHERE ESRN BETWEEN 25 AND 34

Now that we have paging built into the EntitySpaces architecture our new esDataSource control for ASP.NET will expose a PageSize property that you can set. The esDataSource control will then perform all of the paging logic for you automatically. You will be able to build sortable pages that can add, edit, and delete and page through data in a matter of minutes.

The EntitySpaces Team
--
EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET
http://www.entityspaces.net/

A new version of MyGeneration is soon to be released. Below is a screen shot of MyGeneration browsing the Microsoft SQL CE Northwind.sdf database.

The Microsoft SQL CE Support was implemented using MyGeneration's new MyMeta PlugIn support which makes it very easy to add additional data providers to MyGeneration.  A new version of MyGeneration will be released on the MyGeneration site within a few days with the latest VistaDB provider as well. MyGeneration just keeps getting better and better .... 

See http://www.mygenerationsoftware.com

Work is coming along quite nicely on our ASP.NET Design Time support for EntitySpaces 2007. Below is a screen shot of the EntitySpaces ASP.NET design time dialog that will allow you to setup your databinding mappings for grids, detail forms, and other controls in ASP.NET. Notice the image shows a GridView being bound to our new esDataSource control right within Visual Studio.

  

The esDataSourceDesigner control uses reflection to locate all of the classes derived from the EntitySpaces esEntityCollection class. However, the esDataSource uses NO reflection. The design time support is in a separate assembly that does not need to be present for runtime and therefore has no bearing on our medium trust support. The design time dialog will allow you to choose which collection to use in your binding. After choosing the desired collection you can then choose which columns to display.  Once you select "Ok" the grid will then add the columns you have chosen as bound columns and also populate the grid with some design time only data so you can see the layout.

The above image is what you will see when you select the "Columns" property in the GridView's options dialog. You can then further customize the order and all of the "normal things" in here as well. Also, Below you can see the DataKeyNames dialog being used to pick the primary keys in the grid.

And finally, EntitySpaces has taken a wiser path than some of the other implementations. The suggested approach by Microsoft is that folks build their queries in the dialog for updates, selects, deletes and so on? Thus, we would have had to have come up with some crazy "text based" query mechanism that is the equivalent of our dynamic query API. This is a non-starter. Instead, we provide a few key events that are called at the appropriate times that will allow you to use our familiar dynamic query API in code (as it should be).
 

Our esDataSource_Select even is used to create our CatagoriesCollection and then load it any way we see fit. We set the esDataSourceSelectEventArgs Collection property to our loaded collection.

    e.Collection = cats;
}

There is currently only one other event that needs hooked up and that is the CreateEntity event. However, we are providing many more events that will allow you to fully customize everything if you desire to. However, you will only need to handle two or three events to have a fully editable grid or other control working with add/edit/delete functionality. This will be included in our next EntitySpaces 2007 beta. There are a few issues of course still that we are still working out but our thinking is this is really going to power-up your ASP.NET development.

This isn't the first time I (Mike speaking) have commented on this subject, I have done so once before at least on the MyGeneration forums. However, now that we are implementing EntitySpaces design time data binding support for ASP.NET 2.0 my anger has been renewed ten fold on this subject. To put it bluntly, Microsoft ruined ASP.NET programming when they released ASP.NET 2.0. Quite a statement I agree, however, I'm not the only one who thinks that. I've been communicating with several key folks in the know concerning this new ObjectDataSource/DataSourceControl fiasco and received this comment just today.

"IMHO, Microsoft ruined data binding in ASP.NET 2.0 when they dropped component support from the design surface"

What am I talking about? Well, if you have ever used data objects or business objects that support the proper interfaces you can drag then right out onto your form, add them as the datasource to your grid, and then pick which columns you want to use, and in what order, including sorting, and so on. You can do that now with EntitySpaces in Windows.Forms, but all that was removed from ASP.NET 2.0. Why? Let's go back in time and look at the reason Microsoft gave (and still gives) as the reason they decided to remove design time data binding support from the ASP.NET 2.0 Framework. 

Microsoft's Statement on this:
http://lab.msdn.microsoft.com/ProductFeedback/viewfeedback.aspx?feedbackid=e2996990-64a5-4308-921d-245071e6f174

Thank you, we appreciate all of the feedback on this issue. Unfortunately we will not be able to implement a Component Tray for components in VS 2005. As stated previously, the existing model in VS 2003 was prone to bugs and code-loss and as such we've removed the functionality of a designer tray for components defined in InitializeComponent. The team understands the desire to have this functionality and we will look at potential solutions in future releases which are more robust. While the designer tray support for components declared in Initialize component is removed, components themselves are fully supported and can be edited by modifying code, and existing components defined in pages will not break and will continue to work when the page is executed.

We regret the loss of functionality in this scenario and we will certainly aim to provide similar functionality which is realizable and not error prone in future versions of Visual Studio.

My Paraphrase: "We couldn't get it to work?"

So, what does this mean. It means Microsoft hurt immensely the development communities ability to write ASP.NET applications in 2.0. There is just no way around it. To say that they couldn't figure it out is insulting to the say the least. They should have picked up the phone and called me, I guarantee I could have had made it work. No, there had to be another reason and I think I know what it is, more on that later in this post.

One of those sounding the warning sirens early on was Daniel Cazzulino and you can see his blog and his replies on the Microsoft link (or rather excuse) above. His responses are as kzu as he urged them to re-open this issue. In fact, I remember that post being much longer, a lot of it has been removed, I wonder why? He was so right of course, thanks Daniel, but there was nothing you could do, it wasn't that they couldn't fix it, it was removed for a purpose.

So, left trying to pick up the pieces are the ORM folks, from Paul Wilson, Rockford Lhotka, Frans Bouma, and Winston Fassett's work surrounding NHibernate, and probably quite a few others I have left out. On Rocky's Blog Post you can see his frustration and rightly so, remember, this all worked via generic interfaces like IBindlingList and ITypedList and so on in ASP.NET 1.1 .... Paul Wilson's DataSourceControl sample is cool, but one thing you learn very quickly is that his sample, while appreciated, merely allows for runtime data binding. All that work just for runtime databinding?  Then there's Winston Fassett's NHibernate Example on The Code Project which takes it a little further.

However, and I must say, NONE of these samples are actually what you would call design time data binding support. This is not to discredit anyone's work, their work is good. The point is everyone is being fooled into believing that this is something that it is not; DataSourceControl is not a replacement for ASP.NET Design Time data binding and neither is ObjectDataSource. Take a look at this image from the NHibernate based article.
 

Notice the TypeName property is Northwind.Model.Product. This is the type of object you want to bind to, which is then loaded via reflection in both Paul's and Winton's samples. In fact, there really is no other way to do it. So medium trust goes out the window. Also, if you look closely you will see things like WhereFragments and SelectParameters and other strange items. It quickly becomes evident that this is a strange and rather bizarre way to create a web page. Rather than write the code in a code behind page to load the entity you get to use a strange dialog with a dialect completely different than your normal way of working. And the vendor of the ORM architecture get's to invent an entirely new API to query the objects since you cannot use C# or strongly typed mechanisms in a dialog like this. 

Look at these methods of the low level DataSourceView class that Microsoft holds out as a better way?

virtual int ExecuteUpdate(IDictionary keys, IDictionary values, IDictionary oldValues);
virtual int ExecuteDelete(IDictionary keys, IDictionary oldValues);
virtual int ExecuteInsert(IDictionary values);

So, Microsoft now expects us to actually write our insert/delete/update statements by passing IDictionary's of typeless data around and using reflection to translate those into properties in order to make sure any business logic that needs to be executed is triggered. I'm getting pretty ticked just writing this up. Am I the only one who see's this? This isn't design time data binding or even runtime data binding, this is worse than scripting, in fact, none of this is necessary at all, just support IBindingList and ITypeList and you can write your code in C# or VB.NET and not in some strange bizarre dialog? This type of programming would make me long for VB4 if there ever was such a thing ....

I have yet to find a simple sample of a grid binding to a business object (like we used to be able to do in the .NET 1.1 Framework) using this new scheme they've hatched. I've tried to hold my tongue and not bash, but this one deserves bashing, whoever dreamed up this monstrosity obviously had no idea what was lost and no idea what object oriented programming or strongly typed programming is. Instead, they come up with update/delete/select methods that take IDictionary's. They must have been using a raw ADO.NET datatable with no foresight beyond that. In a way I feel sorry for them, they had nothing else to go by, they haven't created nor probably ever used a well written architecture like EntitySpaces or some of the others mentioned above.  And that leads me to my conclusion.

For Microsoft to say "We regret the loss of functionality in this scenario and we will certainly aim to provide similar functionality which is realizable and not error prone in future versions of Visual Studio" is disingenuous. Does anybody reading this believe Microsoft on this? The company that creates massive development teams just to release free products like Sql Ce couldn't get this minor issue to work in ASP.NET 2.0? One of their most important products?  Honestly, I'm appalled at this statement.

Could it be that ASP.NET design time support was dropped to allow Microsoft time to work on ADO.NET vNext while at the same time severely hampering those vendors who stood to gain a dominance in the very important ORM market, a market that Microsoft thus far is severely lacking a presence in? It will be interesting to see if by miracle this "loss of functionality" is restored in conjunction with the release of ADO.NET vNext. Perhaps there will be a new model released as what exists now is frankly, worse than nothing. My guess is a miracle is on the horizon.

  


EntitySpaces 1.6 has been renamed EntitySpaces 2007. This does not imply that we have adopted a 1 year release schedule by any means. Our versioning will be as follows. An assembly version of 2007.4.0804 is broken down as follows; 2007 is the year, 4 is the release, 0804 represents August 4th. However, we will no longer refer to our releases by the assembly versions, instead, if the assembly version is 2007.4.0804 we will refer to it as "EntitySpaces 2007 v4". Each new release will bump the assemblies accordingly. We feel that this is a much better way of communicating our release numbers while at the same time providing some context on the age of any given release.

There is one exception to our new versioning convention and this will occur during beta releases. Upon our first release of the EntitySpaces 2007 beta the assembly versions will be 2007.0.0304 where 2007 is the year, 0 is the release, 0304 is March 4th. We will refer to this as EntitySpaces 2007 Beta v0.0304. During beta releases the release number will not be incremented, only the date portion will be. If the next beta were to be released on March 21st the assembly versions will be 2007.0.0321 and we will refer to this as EntitySpaces Beta 2007 v0.0321.  The official release of EntitySpaces 2007 will be EntitySpaces 2007 v1.

The EntitySpaces Team
--
EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET
http://www.entityspaces.net/

Another area of enhancement is complete, and that is our improvements to the EntitySpaces Dynamic Query API. We took some steps not covered in this blog post to hide extraneous items from the intellisense when building Dynamic Query's via intellisense. We have also opened the door to all kinds of SubOperators, some simple samples are shown below, of course these work on all of the EntitySpaces data providers as well. It is our hope that during our 1.6 beta our users will suggest more SubOperators, and as long as they apply across most databases there's a good chance they will make the release.

So here's the Sneak Peak ...

Notice the ToLower() SubOperator and the As() aliasing mechanism. These are both new to the 1.6 DynamicQuery Mechanism.

Employees emp = new Employees();
emp.Query.Select(emp.Query.LastName.ToLower().As("LastNameLower"));
emp.Query.Where(emp.Query.EmployeeID == 1);
emp.Query.Load();

Generates ...

SELECT LOWER([LastName]) AS 'LastNameLower' FROM [Employees] WHERE ([EmployeeID] = @EmployeeID1)

Employees emp = new Employees();
emp.Query.Select(emp.Query.LastName.LTrim().Substring(0,1).As("FirstInitial"));
emp.Query.Where(emp.Query.EmployeeID == 1);
emp.Query.Load();

Generates ...

SELECT LTRIM(SUBSTRING([LastName],0,1)) AS 'FirstInitial' FROM [Employees] WHERE ([EmployeeID] = @EmployeeID1)

Finally, the Aggregates underwent a breaking change, it will be very easy to upgrade these and we felt it important to have our Aggregates conform with the rest of the syntax. We apologize for the breaking change but felt it important to make this change now. We feel that when you look at the two syntax's shown below you will agree the 1.6 syntax is superior and really shines with intellisense.

1.5.3 Syntax
emp.Query.Select(emp.Query.LastName.Count("TheCount", true));

1.6.0 Syntax
emp.Query.Select(emp.Query.LastName.Count().Distinct().As("TheCount"));

• ToUpper
• ToLower
• LTrim
• RTrim
• Trim
• Substring

There are many more that can be implemented, the architecture is now in place to support them and the syntax nests properly as you can see in the Substring example above. Something we've been thinking about that won't make our 1.6 Release but will find it's way onto an upcoming Roadmap is SubSelects. We already support the IN in the where clause of course. We're not sure on the syntax but perhaps something like this:

Future Roadmap ....

Customers cust = new Customers();
Employees emp = new Employees();

emp.Query.Select(emp.Query.EmployeeID, emp.Query.FirstName);
emp.Query.Where(emp.Query.EmployeeID.In
(
     emp.Query.SubSelect(cust.Query.Location == "Indianapolis");
)
emp.Query.Load();

The EntitySpaces Team
--
EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET 2.0
http://www.entityspaces.net/

We are working hard on our upcoming 1.6 release and we are very excited about it. EntitySpaces 1.6 is going to deliver a truly amazing set of features. The EntitySpaces esTransactionScope class is being greatly enhanced to provide even more power and flexibility for your enterprise level development projects. Before we begin, however, a little background is in order.

Before the Microsoft .NET Framework was released most of my development (Mike) involved creating COM+ object models on top of SQL Server using C++. These objects models would then be consumed by VBScript programmers to create corporate websites. This might date me a little but I was there when OLE 1.0 was released. Later, when NT Service Pack 4 was released MTS became a serious technology and it really got interesting. Finally, it was all rolled into Windows NT itself as COM+. I designed many large Distributed Network Architectures (DNA) using COM+ to protect several concurrent SQL Servers / MSMQ servers which then delivered packets to EIA brokers, all in a single distributed transaction. It was the stuff dreams are made of. If it's one thing I know, it's that the transaction is the heart of any architecture and should be front and center in your ORM solution. In the end, before the dawn of .NET, I was using the Active Template Library (ATL) in combination with the Standard Template Library (STL) to create incredibly high performing distributed network architectures. Indeed, ATL and STL in the right hands was a deadly weapon.

When Microsoft .NET was released I created dOOdads (back in the leather helmet days). I used COM+ as my inspiration. There was no way I was going to do what most of the industry was doing and that was passing Transactions and Connections around all throughout my API, it had to be seamless. Thus, I used Thread Local Storage (TLS) and stuffed the Transaction into a slot on the thread. Then, down low in the architecture the base classes simply enlisted into the transaction, if there was an ongoing transaction. To the programmer it's magic.

If you are familiar with the TransactionScope class in the Microsoft .NET System.Transactions namespace then you will be very comfortable with the EntitySpaces esTransactionScope class. The really cool thing about the .NET TransactionScope is how it uses the "using" syntax to control the transactions "scope" or lifetime. EntitySpaces runs fine using the .NET TransactionScope, however the System.Transactions.TransactionScope class can add some significant overhead if you are not in need of distributed transactions. The .NET TransactionScope is a truly amazing work of art itself in the way it can promote local lightweight transactions to distributed transactions when another resource is enlisted. However, there is a certain amount of overhead when using the .NET TransactionScope class and most hosting companies will not allow you use the .NET TransactionScope class as it enlists the Distributed Transaction Coordinator (DTS). 

In summary, the esTransactionScope class uses Thread Local Storage (TLS) to avoid intrusion and takes advantage of the the "using" syntax to control a transactions "lifetime". The esTransactionScope fills a very noticeable void in the Microsoft .NET Framework, and that is an elegant solution for ADO.NET connection based transactions.

Currently, in our 1.5 release esTransactionScope can be nested as follows:

using (esTransactionScope scope = new esTransactionScope())
{
    Employees emp = new Employees();
    emp.LoadByPrimaryKey(1);
    emp.FirstName = "Joe";
    emp.Save();

    Customers cust = new Customers();
    // ...
    cust.Save();

    scope.Complete();
}

In the code above, both the Employees and Customer Save methods also use the esTransactionScope, they can be nested just fine. Only when the final outer scope.Complete() is executed is the transaction truly committed. However, there are times when you might want to write to a SQL table during an exception possibly caused by a rolled back transaction, for instance, to record the callstack information. Or you might just otherwise need to break out of an ongoing transaction. You might even want to have a nested transaction that acts as it's own root transaction much like a COM+ requires new transaction. We have added this granular level of control in the enhanced 1.6 esTransactionScope class. The ability to nest all of these different types at your leisure greatly enhances your power to accomplish what you need to with EntitySpaces. In our 1.6 release the esTransactionScope accepts an optional parameter on it's constructor, and that is the esTransactionScopeOption enum.

public enum esTransactionScopeOption
{
    // Summary:
    //     A transaction is required by the scope. It uses an ongoing transaction if
    //     one already exists. Otherwise, it creates a new transaction before entering
    //     the scope. This is the default value.
    Required = 0,
    //
    // Summary:
    //     A new transaction is always created for the scope.
    RequiresNew = 1,
    //
    // Summary:
    //     Any ongoing transaction is suppressed when creating the scope. All
    //     operations within the scope are done without a transaction.
    Suppress = 2,
}

The following code snippet shows how you can nest and control the transactions at a very granular level. However, our recommendation is to run with Required for all nested transactions. You must be careful not to create deadlocks. The default isolation level of esTransactionScope is Serializable, which offers the most protection.

using (esTransactionScope rootTrans1 = new esTransactionScope())
{
    using (esTransactionScope noTrans = new esTransactionScope(esTransactionScopeOption.Suppress))
    {
        // Anything done in here runs without a transaction because of the "Suppress"
        esUtility util = new esUtility();
        int count = (int)util.ExecuteScalar(esQueryType.Text, "Select Count(*) From Employees");

        using (esTransactionScope scope = new esTransactionScope())
        {
            // This transaction scope uses the default is Required, therefore it enlists in "rootTrans1"
            Employees emp = new Employees();
            emp.LoadByPrimaryKey(1);
            emp.FirstName = "Joe";
            emp.Save();

            using (esTransactionScope rootTrans2 = new esTransactionScope(esTransactionScopeOption.RequiresNew))
            {
                // This is a new root transaction and doesn't partake in "rootTrans1"
                Employees emp1 = new Employees();
                emp1.LoadByPrimaryKey(2);
                emp1.FirstName = "Sam";
                emp1.Save();

                // Since this was a RequiresNew tranaction, the true commit is done here
                rootTrans2.Complete();
            }

            // Doesn't commit yet, as "rootTrans1" is the root
            scope.Complete();
        }

        noTrans.Complete();
    }

    // Commits the rootTrans1 and any nested transactions
    rootTrans1.Complete();
}

If you were paying attention to the above code you might have noticed the new esUtility class, this class allows you to execute any SQL without using a specific EntitySpaces Collection or Entity, thus the name, esUtility. This is just a sneak peak and we will post many more of these to give you insights into our next release.

The EntitySpaces Team
--
EntitySpaces LLC
Persistence Layer and Business Objects for Microsoft .NET 2.0
http://www.entityspaces.net/