Was sitting here and putting some finishing touches on some new modules that we will be releasing this month, and the thoughts of DNN 2.0 crossed my mind. Thus, I sat back, wondered and pondered a bit with my coffee in hand.

I would like to hear what other developer's thoughts are with DAL and new BLL support. Are you going to support / supply only the commonly supported DAL databases, or include in the scripts to run against other engines as DAL layers become available for other database engines? Are you worried about cross version compatability issues with 2.0 and 1.x code bases (do a quick search on Google and you find alot of sites still running 1.0.x (7, 8 or 9). Making a module only 2.0 compliant misses out a large customer base.

Just for some info on what we've decided:

1) all database changes are done using PowerDesigner (pick your fav modelling tool here)
2) database code is generated for the various db's from the datamodelling software.
3) views / sprocs are generated using codesmith from the tables to handle the standard CRUD transactions (limits our involvement to the SPROC creation down to only non-standard CRUD and query SPROC's)
4) create DAL generated code (since we didn't have DAL, created our own database abstracted layer) using codesmith
5) create objects based upon dal for BLL / ByDesign's DAL seperation using codesmith to allow for 2.0 migration if required.

However - it leaves one to a question of supportability and relibility across multiple database vendors (ie: Oracle, Sybase, MySql, SQL Server, etc).

It's great that Core supports multiple databases, but it is rather pointless if you can't run your favourite module add-on in the other database as well - correct?

And of course, if the module development and support starts costing developers $$, how much longer can we expect free modules to be available for the quality and breadth that they are now?

Features and extenibility is wonderful, but I'm wondering if we've changed the DNN economics a bit during all of this....

--Richard

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.

I feel that the DAL is going to bring in more users that otherwise might not contribute. For example the cut and paste programmer that is starting to learn. Everyone hates access (and I hate it also) but for people that do not have SQL server and want to learn DotNet this will be a perfect opportunity.

There are two types of modules. Free ones and paied ones ?I think it will break down like this.

Paid ones ? The develops that can support all of the Data access layers will do better than the ones that can?t and if no one is doing it at first then someone will

Free ones- If they are free then its all good? I release a free module that only provides SQL server support?some guy running mySQL sees it and likes it allot and he build the DAL for mySQL.

DotNetNuke is valuable for many reason but I feel that it one of its strongest points is the learning environment it creates. I am a DBA by trade but I have been learning DotNet by coding and playing with DotNetNuke. As the user base grows more people will use it as a tool to learn and hopefully pass some of there experiences back to the community.

My .02
Bert

So Richard, it seems you like codesmith?have you looked at LLBLGenPRo I have heard good things about it also and was wondering how you felt about it

I use LLBLGenPro for my other developments -- its awesome, :)

---

Modules, Skins & Skin Objects @ www.smcculloch.net

I think the hardest part for most developers will just be having the DB to test against. I know personally I don't have Oracle to test against for instance and it's a pain to set up and run multiple DBs just for module testing. That said, the way to go about it will be fairly straight forward now and should work well for those who put in the effort. I suspect that SQL Server, Access, and MySQL will get the most use by developers of free modules but I expect that comercial modules may well support other DBs, Our whole effort here is to open DNN to a wider market and that's a good thing for module developers.

I too look forward to other developer comments on this issue though. The DNN code is changing every day on GDN (but usually it's still functional), but hopefully the DAL whitepaper helps developers understand the philosophy of what we are trying to accomplish and the reasons that certain design decisions were made. I hope the developer community supports DNN's move into a more flexible open environment and helps it flourish and not let it flounder with incompatibilities between DB's. For that to happen I know that we will need to provide solid documentaion and support for the module developers out there.

I hope we can accomplish that goal and that the developer community helps us achieve it.

Jeremy

---

Jeremy White
Webstone, LLC
My DNN Blog

I agree with the points made, but it brings me to thinking back to the not so past history of...well, you can run this application, if you use this version of windows, it's suported under this version, but not under this version, only supported with this version if you run naked through the woods screaming "I hate OS/2".....but I digress...*smiles*

In essense, DNN 2.0 is creating different forks for module developers. Do you only support core DAL, or provide the entensions for other databases. I have MySQL and SQL Server already loaded on my development servers, but heck, if I have to support Oracle and DB2, the incremental cost in which you have to pass along via your module cost, just increased dramatically (not to mention memory footprint!). (We won't mention access here, if I have to develop on that, I just might cry)

Let's say the average modules sells 200 copies, increased development costs of say, 3000 USD, means a rough passing of 15 USD per module....hmmmm...not much, but that's not including support, etc - and the fact that once you get into Oracle and other DB's, now you compound the problem of DB versions (supporting sql server 6/7, oracle 8i, 9i, mysql 4.x.x....) Things start becoming quite hairy. *fast* Then combine that with DNN version upgrades, module upgrades as development and production lifecycles continue forward....Then of course, you get the lovely support emails, "I'm running the portal under Oracle 7 - how come you don't work??"

A module that costs 15 USD now, and quite affordable to the general public might be a money losing proposition for the developer to support DNN 2.0 across a variety of database platforms. Ie: module for 1.x version of DNN stays at 15 USD, 2.0 DNN with multi-db support costs 40 USD. I could see that happening quite easily.

Some things that might kill DNN 2.0 as a sucessful "business" implementation (I have no doubt that core team will make it a great technical implementation - and I'm damn well chomping at the bit for a beta!)

1) Lack of third party products (remember OS/2)?
2) Lack of real evolutional migration from the community at large (there's still a rather significant number of 1.0 implementations out there, and a great many at 2 or more versions behind current reference implementation of 1.0.10)
3) Price differences between modules for 1.x and 2.x versions of DNN comparable modules because of increased development, maintenance and support costs.

Part of the beauty of DNN is the vast amount of free or relatively inexpensive modules out there in the community at large. Having that breadth of modules, as Shaun put it - makes DotNetNuke closer to other reference portal platforms ie: PHP-nuke. That's my worry.

As far as code smith, the price was right *smiles* - about the only feature I don't like is the fact that you cant save multiple files easily, but it manages to romp through a database and save alot of time and effort doing the mundane tasks. For that, it's definately value for the money. When I get my hands on DAL - I'll create codesmith scripts for it, and have them up, unless someone from core beats me to it *hint*

--Richard

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.

Just a side observation:

I don't see DNN 2.0 being made available anywhere. I thought DNN was an open-source project?

---

Kimberly Lazarski

zoltar@|maqsonNOSPAMmaqson@|biyndevelopment.com

Kimberly,
DNN is Open Source, you can see every line of source for every release of DNN that has ever occured. It comes right with the release.
As for 2.0, it's not ready yet, but we're hiding it in plain sight :) . I eluded to it up above but the source the team is working from is and has been available on the GotDotNet (GDN) workspace for DotNetNuke. Core Team Members upload their changes there as they complete them. We don't talk about it a lot in the forums because for normal users we are just asking for problems. For developers though (especially for 2.0 level architecture changes), it can be useful to examine the code. At this point in the code, there are a couple broken items I know of and not a lot of documentation, the skins are still in the VERY EARLY process of being added and the SQL scripts are probably not complete. We would not suggest ANY user attempt to run this in anything remotely like a production site or even expect that the code will not change between now and the beta. It may not even compile at times. It may be usefully however it you want to see how the DAL has been architected up close and personal. There is no support for anything compiled from this source but once we have a beta ready I'm sure you'll hear about it, and the team will do our best to solve any bugs brought to light then. We should have an official Beta release ready within a couple weeks.

Jeremy

---

Jeremy White
Webstone, LLC
My DNN Blog

Glad to see that you guys are keeping GDN rather fresh as 2.0 goes forward. I'll probably download a copy and take a few peeks around - I'm curious on the container skinning that is in 2.0 and a few other things.

2.0 will probably be the closest so far to a small GAP between our portal environment and core DNN, and I'd like nothing better than to move back to core - but not at a performance or systematic expense. Heck we just got everything working fine here!

So it will definately be nice to take a look at it and see what revisions to code / graphics, etc are necessary to port the environments over. Not looking forward to it, but gotta do it sometime.

Okay, we got off topic...but thanks for the tidbit Jeremy!


--Richard.

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.

I think it's like any other software development. You have to work within the confines of what your resources allow you to develop or implement.

I also wonder about the direction of DNN after the DAL is implemented. I personally feel that it will be a good thing, but that's coming from someone who has access to several major database environments. Personally, I can't put DNN into real production in my company until I can run it against Oracle 9i. We're an Oracle partner and have a major investment in the platform. Our customer base is almost predominately Oracle because our application environment runs on MS, AIX, UNIX & Linux. A strategic decision made years before I came along was to work with Oracle to support all of those environments.

As the chief architect of our firm, I have been working fervently to push our own company towards .NET as the replacement for our current development environment (UNIFACE... ugh). It's been an uphill battle but there is significant interest in using MS as a platform to wrap around the current database environments with .NET and web services. DNN has been a real boon because it shows some content management/user interface best practices theory that I have been evangelizing for a long time. It has also pushed their thinking into a more object oriented development methodology with the concepts of having a basic applicaiton framework with an API for enhancements via a modular approach.

Personally, I have several modules under development for the DNN environment. I've resorted to writing my own data layer, but the redundancy carries a cost at the data interaction layer. My approach has been somewhat of a wait-and-see attitude because we're in that grey area between major releases of DNN. Knowing there are significant architectural changes coming, it doesn't make sense to invest a lot of time in trying to package a module for release. I'd rather wait, get my hands on the new API, and write my modules to support 1.+ or 2, and even an external architecture with a config param. Why should module developers adopt a similar approach to extensibility?.

Personal Opinion - I probably will build nothing but the SQL scripts for DNN. I see no use in the Access/Oracle whatever layers. As stated before, the only way I see these being the least bit useful is if you can run multiple portals on seperate Databases from the same installation. But I don't think that would work too well either, as the Host settings etc. is shared.

Otherwise, why should I code backwards for somebody using Access? Rather push them into SQL.. And havn't heard enough of Oracle to care..

-Russ Johnson - Arkadic

Awwwwwwwww comeon' Russ - aren't you just biting at the bit to start firing up Access and doing some serious development *chuckling*

I do have to agree, however, we probably have to do Access, just so we have core support - most of us probably have Office Professional anyways.

Btw, I assume that the new PA installation toolkit will automatically derive what sql / other scripts to run against the database in use........Maybe the PA installation should have some idiot proofing to detect first of all if the PA is compatable with the DAL layer in use....

If the majority of module developers (say 90%) only support SQL Server, then really is DNN cross database compatiable? hmmmm. It is, without the value add of Open Source - which is the free or inexpensive development of addon's, enhancements, modules, etc....So it becomes a great technical enhancement, but from the business aspect - not so great.

IMHO, MySQL is a good addition to DNN - that's for sure, especially if the user has their own webserver being co-located or managed - considering the upfront costs of a per CPU SQL Server license.


And I'm not biting at the bit to load up Access either *smiles*

--Richard

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.

I can tell you that there is significant interest in DNN from my .gov clients - major metro area muni and county court systems with several hundred million record Oracle databases (docket entries). None of them use SQL Server for their infrastructure and they aren't about to dump Oracle just to be able to run DNN. They would front-end with a Win 2K host environment to add .NET for web application support, but they aren't going to ever jump from Oracle.

DNN is going to have this issue wherever it goes.

Agreed about that scenario - however, again - you will be able to run Core DNN - but how many addon products are you going to get that run Oracle? Again, DAL only extends to the core (which the conversion between SQL Server and Oracle isn't that hard to do in the first place, btw)

DNN won't "support" Oracle, a third party, or a developer or other will release the Oracle DAL - or you create it yourself. And then you have the perpetual "lag" time between subsequent DNN releases and your DAL release....

It would be then your responsibility or the clients to figure out which addon modules they want (ie: forums, etc) and do the DAL or other translation to Oracle for those subsequent modules.

So it's not really "plug and play" to Oracle or any other database that a) isn't supported by Core and b) isn't commonly supported by the module developers.

Which is why I was curious what other module developers were thinking about in this regard.

--Richard

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.

Maybe there's a second tier of opportunity/activity, which is for Oracle, Sybase, et al developers to provide database layer extensions for module developers who don't have the exp. or access to those environments? Or there is a service opportunity for those developers to provide custom implementation services to end-users to extend SQL Server specific modules into the alternate database environments (where licensing is permitted...)

Wow, this could get ugly with each side of the fence going back and forth.
I thought I might add my .02 on this.

First of all Access, get real...most developers know the limitations here and the only ones who would use this are home users and those who won't spend a couple dollars for a host that supports SQL and they are available for 5 bucks a month or even less who knows.
The only use I can see is for testing without a SQL server but performance issues on a production site could kill your sites reputation.

MySQL....I can't say much here as I have had it available for years and have never used it. My understanding is it is a low cost SQL wanna be.

Oracle...never touched it....

Anyway what I'm trying to say is I feel those that want to use these database options should sit down and start coding or be willing to pay extra for someone else to do it for them.
You can't expect module developers to include options for everyone else plus each version of DNN and give it away or sell it for dirt cheap prices.

And you non-developers don't get me wrong....I am not against you but hwy should others have to give away what they have learned just because you don't want to open a book and learn it yourself. You pay big money to buy a house or car because you can't build it yourself, why is this any different.

Most developers do this because they love it and it's in their blood but it would be nice once in a while for people to appreciate the time they spent building it while you were off having fun somewhere else.

I have probably made many people hate me with this post but maybe it will make some of them think more before they wine about the cost of a module they really would like to have on their site.

My thought...leave it alone with SQL....

---

http://www.dnnfaq.com

http://www.websplus.net

http://www.sdarchery.com

just so people understand, it will not be that hard to create the DAL for a different DB for any given module, especially if you have the source. Here is an example of what it would take to change a SQL DAL to an Access DAL for one SPROC in the survey module (there are 1 or 2 other small line changes at the beginning of the file but this is where the meat is at).

SQL Server DAL Code for AddSurvey:

        Public Overrides Sub AddSurvey(ByVal ModuleId As Integer, ByVal Question As String, ByVal ViewOrder As String, ByVal OptionType As String, ByVal UserName As String)


            SqlHelper.ExecuteNonQuery(ConnectionString, DatabaseOwner & ObjectQualifier & "AddSurvey", ModuleId, Question, IIf(ViewOrder <> "", ViewOrder, DBNull.Value), OptionType, UserName)


        End Sub

Access DAL Code for Add Survey:

        Public Overrides Sub AddSurvey(ByVal ModuleId As Integer, ByVal Question As String, ByVal ViewOrder As String, ByVal OptionType As String, ByVal UserName As String)


            OleDBHelper.ExecuteNonQuery(ConnectionString, CommandType.StoredProcedure, ObjectQualifier & "AddSurvey", _


                New OleDbParameter("@ModuleId", ModuleId), _


                New OleDbParameter("@Question", Question), _


                New OleDbParameter("@ViewOrder", IIf(ViewOrder <> "", ViewOrder, DBNull.Value)), _


                New OleDbParameter("@OptionType", OptionType), _


                New OleDbParameter("@UserName", UserName))


        End Sub

Not really a huge change in code, just a different syntax for the parameters. (and this is for Access, other DB's should likely be less complicated to code and will hopefully look more like the SQL Server one)

Everything has been turned into simple CRUD (Create Read Update Delete) procedures/queries. All the data logic should now happen in the module's BLL (i.e. SurveyDB.vb) and be database independent.
In fact, I'll bet money that somebody will create a free code generator that will build a proper DAL for most modules given the SQL one. (heck I've been thinking about it for my own purposes)
Then it comes down to testing. I think that problem will have affordable solutions as well for those that want it after DNN 2.0 comes out.

That's my .03

Jeremy

---

Jeremy White
Webstone, LLC
My DNN Blog

I realized I probably should also show how similar the SQL query code is as well

SQL Server install script for AddSurvey:

drop procedure {databaseOwner}{objectQualifier}AddSurvey


GO





create procedure {databaseOwner}{objectQualifier}AddSurvey





@ModuleID      int,


@Question      nvarchar(500),


@ViewOrder     int,


@OptionType    char(1),


@UserName      nvarchar(100)





as





insert into {objectQualifier}Surveys (ModuleID, Question, ViewOrder, OptionType, CreatedByUser, CreatedDate)


values (@ModuleID, @Question, @ViewOrder, @OptionType, @userName, getdate())





GO

Access install script for AddSurvey:

CREATE PROCEDURE {objectQualifier}AddSurvey ( [@ModuleID] int, [@Question] Text(500), [@ViewOrder] int, [@OptionType] char, [@UserName] Text(100) )


AS


INSERT INTO {objectQualifier}Surveys ( ModuleID, Question, ViewOrder, OptionType, CreatedByUser, CreatedDate)


VALUES ( [@ModuleID], [@Question], [@ViewOrder], [@OptionType], [@UserName], Now());


GO

Again really not that different.

Jeremy

---

Jeremy White
Webstone, LLC
My DNN Blog

Jeremy:

One has never thought that the DAL / SPROC's would be difficult. Now maybe someone on Core team could reverse engineer DNN into a data tool, and thus generate the schemas for all databases....wow...I just might do that *smiles*...got a toy, must play!

Just a thought to throw at Shaun and the rest of the core team though, create a ADO.NET DAL layer. It's obviously not optimized for the specific databases, but would at least provide a stopgap for most people. For most of the queries and language constructs, let ADO worry about the cross-platform handling of databases. Just a thought. That way all you have to do is worry about the database schema (see above) *wink*

azweb:

I agree with Access - I think that's basically used as the lowest common denominator with Core Team - heck, if it works on access, might as well code for binary data files next! *chuckles*

Keep in mind that everyone discussing this issue, IS a module developer, not an end user whining about things. However, the economics and business fundamentals of the software one tends to overlook when writing the latest and greatest of cool code. We are all techies, and dealing with the business and philosphical aspects of what we do tends to get lots after the Page_Init call.

Why I originally started this thread was curiousity what others are debating on doing in regards to this release, and what Core Team's thoughts were on the subject, as it's one in which is hardly discussed, and I hazzard a guess, not given much time for thought in the core team meetings (IMHO) - hey, we all love to code versus deal with the other ____! We are releasing either next month sometime that's potentially the largest PA out there. Over 30 tables, and 150 SPROCS - not to mention about 60 ascx's...Thus my curiousity on cross database compatiability and others viewpoints on this.

As far as Access - not a chance in h*ll - sorry Core Team.
MySQL - most definately - opens the doors to alot of ISP hosting options, co-location and private server options that right now are prohibitively expensive with a 10K USD per CPU license fee for SQL Server.
Sybase, Oracle and others - potentials, but I can see the support for those being by VAR relationships by the consultants that work with DNN (myself included) versus a mainstream environment. Corporate, Government and others have long standing adoption of database standards that a "little" system such as DNN MUST fit into, versus the other way around.

--Richard

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.

With all due respect Richard, it's those whiny end users who represent the economic force behind my career, which at present includes the decision to follow along with DNN for a while to see where it goes as a platform.

Writing content modules and selling them on Snowcovered.com, et al, is a good way to generate some cashflow for individual developers and small shops. It's a way to offset the time spent in front of the screen. But it doesn't represent the big economic opportunity for us as professionals. Its those contracts with the whiny folks at large customers that have kept me in this game for 17 years. That means that as a module developer, if a customer wants their stuff written in COBOL to support a Cincom TOTAL database, then I guess I'd better figure out how to make it happen.

I understand your point from the snapshot view of today, the current DNN community at large, the past year of effort, and the future of the smaller scope of wide catalog of limited platform module releases. However, I hope that just because many developers will choose to stay on SQL Server as their primary platform, that it doesn't deter the advancement of the core framework in the DAL direction. I've already resigned myself to the fact of having to rewrite TTTForums and CalendarPro for TOTAL DB on my own. :-)

chuckles...my first flame on asp.net forums. I should frame it.

With all due respect, read the entire thread of conversation - that comment was in regards to some comments made prior - not a generalistic statement. I have spent alot of my own time assisting "end users" with DNN, either by direct contact, by these forums, or via information on my own site - with no monetary gain - such as others have so helped me ramp up in the past. The idea of any open source project still basically in it's infancy is to get general acceptance from the industry so more wide spread company based adoption is possible (ie: Linux wasn't adopted as a good corporate buzzword until after it's end user advocats had really set it up as a serious player in the internet field)

So with all due respect, consultants focusing on Gov, large corporate clientelle aren't really the focus of this thread - because any consultant would simply get the job done. Period. It should not matter what the core team does in this case - because if you have a business problem to resolve - technology should never define the business requirements.

To be blunt, consultants have a more freedom in how you are taking development - and quite honestly, any consultant should have been able to take 1.0.9 or 1.0.10 to another db without waiting until 2.0 came out - it's not exactly that difficult. That's what consultants do. Unless my years in that field are not indicative of the industry on the whole. As a matter of fact, if you wanted to lock down a significant portion of work, you would have already ported DNN to Oracle, Sybase, etc - as the proof of concept show of your company's capabilities.

The real question was - DAL is here - now what?

If joe client, with a limited (or zippo) budget wants a DNN website running under MySQL, and wants module B, C and D - but MySQL implementations only have modules B and D, Oracle as C and D, and SyBase has B and D Version 1.1 - Joe is going to get mixed thoughts about implementing DNN. He doesn't care that oh yes, core DNN can support the highly advanced technical achievement of running under multiple databases and he isn't looking for a hot consultant to re-work his site to work under MySQL the way he feels it should - he's looking for something nice, running under ASP.NET that provides the richness as the other reference portals such as PHP-Nuke. That's a potential customer that might simply go off in another direction.

--Richard

---

ByDesignWebSights
www.dotnetnuke-modules.com
Portal Store, Advanced Email Manager, SiteTrack, Support Desk and many other modules for your DNN platform.