I was catching up a bit the other day, got to http://community.entityspaces.net/forums/thread/228.aspx, read Mike's comment "write a module using the DNN DAL then write the same using EntitySpaces, you'll never look back" and realized that's exactly what I did.

About a year ago, I built a site with about 20 custom models and realized I was using as much time writing and maintaining CRUD as I was doing other useful work.  I tried DAL Builder Pro and it helped some.  Tried ATGen and DAL2.  Tried a couple of other ORM tools.  Then I tried EntitySpaces.  Wow - once I create the tables, I can click a couple of buttons and the CRUD/DAL is complete!  Plus, I've got autocomplete design time support and access to all the great stuff Scott mentioned in the post above.  Now, instead of dreading schema changes, it's a piece of cake - just make the change and regenerate.  If I miss a change in code, the compile catches it.  Sweet!

A few months later, hierarchical support was added which sure is convenient.

The new esDataSource saves even more time.  Creating an Administrative grid or adding databound Dropdown lists is quick.  Looking back on my thinking, I was a bit naive about the possibility of using the automatic GRID Insert/Update/Delete capabilities for production user interfaces.  In fact I've decided so far to stick with the standard View/Edit model which DNN uses since it seems more straightforward in terms of adding/accessing controls and usability. 

Using EntitySpaces is so darn productive, it's ludicrous to think about going back.  Add Telerik (or MS GridView) and Peters Validation (or Date package), etc. and life is darn good.  EntitySpaces is definitely the best money I've spent (except the engagement ring :-).

So far, the things I've tried with the latest Beta and r.a.d. Grid seem to work correctly (with the previous beta, I was able to crash Visual Studio when I regenerated the Schema after closing the ascx and re-opening).

A some questions/suggestions:

• A minor item - I'm not sure where you're keeping the esDataSource configuration (assembly, entity, and columns).  Does it make sense to add them as properties, which are configurable in the control definition in the ascx/aspx?  It might save a little time if you're adding a bunch of datasources (I created a userControl the other day with a number of drodownlists) if you could just type in another entity and it would be nice not to have to re-pick the Assembly.
• Looking for advice here - I've been using file-based web development with DotNetNuke.  After reading http://community.entityspaces.net/forums/thread/1125.aspx I was wondering - should I move to webprojects?
• Just to be clear - WRT http://community.entityspaces.net/forums/thread/10.aspx - if all of the modules use the DotNetNuke SQL Server Database, there's no reason not to use the default ES connection that I've always had in web.config, correct?
• Sorry to hear that Microsoft screwed up the design-time support so badly.  I wonder if anyone is keeping an eye on "Orcas"?
• It's great that you're testing with Telerik's Grid.  I might also try testing with the treeview once hierarchical support is added.
• For the medium trust loader, is there any reason not to simply add the following code to Application_Start in Global.asax.vb (which comes with DotNetNuke):

Code:

' EntitySpaces medium trust loader
EntitySpaces.Interfaces.esProviderFactory.Factory = New EntitySpaces.LoaderMT.esDataProviderFactory()

Every time I look, you guys are making life easier!

First, the EntitySpaces team is very pleased with your kind comments. We knew that esDataSource was key for EntitySpaces to really make things easier and it will get better by the time we release even. I'm running low on time, let me post back on your questions/suggestions when I can give them the time they deserve. Again, thankyou, and yes, the Telerik controls are sweet.

---

EntitySpaces | Twitter | BLOG | Please honor our Software License

Brief thoughts...

WAP vs WSP - its entirely dependent upon your situation. Each has their own benefits and downsides. EntitySpaces works equally as well with both. 

For all most all of your other config questions, if you 'own' the portal and have complete control over it, then you can use whatever config you want. A lot of users in the modular software world do not have that convenience, and that is why we suggest the methodologies we do.

Thanks for you kind words, doing a lot of DNN development myself I couldn't agree more;) 

 

---

Regards,

Scott Schecter
EntitySpaces | My Site

Thanks for the replys!

Mike - no problem it's not urgent.

Scott - the 1st part of your reply might be directed toward one of the posts from TSchwingle (WAP Development - Adding esDataSource to DNN Module or WAP Development - Adding esDataSource to DNN Module )?

Hey Mike,

Just wanted to check in to see whether now was a good time to get your thoughts?

Stupid2Rules:

A some questions/suggestions:

• A minor item - I'm not sure where you're keeping the esDataSource configuration (assembly, entity, and columns).  Does it make sense to add them as properties, which are configurable in the control definition in the ascx/aspx?  It might save a little time if you're adding a bunch of datasources (I created a userControl the other day with a number of drodownlists) if you could just type in another entity and it would be nice not to have to re-pick the Assembly.
• Looking for advice here - I've been using file-based web development with DotNetNuke.  After reading http://community.entityspaces.net/forums/thread/1125.aspx I was wondering - should I move to webprojects?
• Just to be clear - WRT http://community.entityspaces.net/forums/thread/10.aspx - if all of the modules use the DotNetNuke SQL Server Database, there's no reason not to use the default ES connection that I've always had in web.config, correct?
• Sorry to hear that Microsoft screwed up the design-time support so badly.  I wonder if anyone is keeping an eye on "Orcas"?
• It's great that you're testing with Telerik's Grid.  I might also try testing with the treeview once hierarchical support is added.
• For the medium trust loader, is there any reason not to simply add the following code to Application_Start in Global.asax.vb (which comes with DotNetNuke):

Code:

' EntitySpaces medium trust loader
EntitySpaces.Interfaces.esProviderFactory.Factory = New EntitySpaces.LoaderMT.esDataProviderFactory()

Every time I look, you guys are making life easier!

My apologies, I got list in the pressure cooker of ES2007.

A minor item - I'm not sure where you're keeping the esDataSource configuration (assembly, entity, and columns).  Does it make sense to add them as properties, which are configurable in the control definition in the ascx/aspx?  It might save a little time if you're adding a bunch of datasources (I created a userControl the other day with a number of drodownlists) if you could just type in another entity and it would be nice not to have to re-pick the Assembly.

This ability didn't make it into ES2007, however it is my plan to have this in our follow on release in early July. I know, it's really needed. It could be that we put these in the control definition. That's a great idea really, this way defining an esDataSource in pure html would be very easy.  I think that is exactly how I'll do it.

Looking for advice here - I've been using file-based web development with DotNetNuke.  After reading http://community.entityspaces.net/forums/thread/1125.aspx I was wondering - should I move to webprojects?

It sure makes it easier to use the esDataSource, even easier if your business objects (Generated and Custom) are in their own assembly. However, it's possible to do even in the file based approach, it's just a little more difficult. I think Scott told me a few weeks ago he's using the solution based projects now for everything he does. 

If all of the modules use the DotNetNuke SQL Server Database, there's no reason not to use the default ES connection that I've always had in web.config, correct?

Yes, if you're running your own DNN site that's exactly how I'd do it. However, if you're doing commerical dnn modules we strongly recommend configless registration. Did you notice the new ability in ES2007 to point to an existing connection string in the standard windows connectionString area? You could use that as well to pull the existing DNN connection I think and not have the connection string in their twice, but Scott is really our DNN guru. It should work however just fine.

I wonder if anyone is keeping an eye on "Orcas"?

Yes, we'll have some blog posts on this soon, wait for those, a big topic.

 I might also try testing with the treeview once hierarchical support is added.

Hierarchical binding is one of the big features coming in a follow on ES2007 release, that and the persistent esDataSource mappings mentioned in the first item above. It really is pretty simple for us to do at this point.

 For the medium trust loader, is there any reason not to simply add the following code to Application_Start in Global.asax.vb (which comes with DotNetNuke):

 Yes, again, if your developing your own site like we do for our ES site then yes, it would make it very easy just to add it in here and forget about it.

 

I hope that helps, if you have follow ups feel free to ask, I can alert Scott to this post too, he's our DNN guru and can probably shed more light ... 

 

---

EntitySpaces | Twitter | BLOG | Please honor our Software License