I do most of my heavy lifting in storeprocedures.  I  implement the data access as one big layer. Separate from the presentation layer. This allows me to use the data layer in either a windows ui or asp pages.

I created a code generator that builds the data acess layer for me.  This allows me to easily regenerate the data-access layer anytime i make changes to the database.

I recommend the following book Code Generation in Micosoft .Net by K Dollard. Is not a dnn related book but it has some great insights on how to architect your projects for code generation.

Regards

ray

I don't know of any drawback, other that you will be doing things your way instead of the dnn way of doing things.  If you intend to sell your app to dnn module/developers that could be a drawback, since they have to learn your way of doings things.

What type of application are you developing?

Is it strictly ASP .NET, or do you plan to have backend, that runs in windows?

Are you using a separate database for you application? 

You need to consider security/roles etc and how they relate to your app and syncing your user tables with the dnn user tables.

Regards

ray

swonderme wrote:

I'm building a single, large-scale application in DNN that will contain multiple modules (probably 30 to 40)  and it's own data model.  Basically, I'm using DNN as my application architecture to take advantage of it's security model, content management, look and feel, dynamic page creation, etc...  I'm new to DNN, but have been programming in vb, c#, and other languages for a long time. 

It seems that each DNN module has it's own data layer that handles its one or maybe two tables.  Since I'm building a complete application, each of my modules will focus on at least of couple of tables from my data model, but all will at least refernce other tables as well.  In addition I may have some complicated modules that may use many, many tables from my data model.

What's the best way to approach this?  Should I create a little tiny data layer for each module that just deals with the specific tables that a particular module deals with, or should I create one data layer project containing all my tables and just reference that one project in each module?  If I do that (one data layer) will it work, and how would I go about it exactly?  Just create a project (or a solution?), build my data layer code, compile it, and reference that one project in each module? 

I know that most modules just have their own data layer, but how does the core handle this?  I assume they have one data layer with every table in it?  And then each core programmer just references that single data layer?

Any of you folks that have built an application that spans many, many modules and has one large data model.....how did you handle your data layer?  One big one or many smal ones?  It seems like for my situation one data layer is the way to go, but I'd love to hear how other people have done this, and I'd love to see a quick example or verbal walk through if any would care to help me out.  I'll give back as I get rolling on this project as I discover and write new and useful tools.

Or, if there's anything I'm missing or if I am coming at this from the wrong angle, please let me know.

Thanks all.

Dear all

I've got similar situation. Impressed with DNN and still learning it as to how it can be extended (may be, DNN for entrprise-like functionalities - ERPs, SCMs, and CRMs).

Here's what I am envisioning (and would like all PROs in this group to please comment, guide and share their experiences):

Use DNN framework and leverage it's core to build ERP like functional modules (say financials, pruchasing, mfg etc.)

Questions:

1: Has anyone in DNN community has done any similar work yet?

2: If Yes, what's your experience?

3: How DNN can be extended for big DALs and extended ERP-like functionalities that are usually not seen other than ERPs (flexible atchitecture, dynamic data access etc.)

3: If No, should I consider that DNN is only a good CMS and should not be considered to extend or interfaced with ERP-like functionalities?

Any of your comments will be really of great help!

Best regards

Alex

Dear swonderme

Thanks for your reply.

One thing, we are on the same boat and need more directions from DotNetNuker.

Also, the points you quoted are very valid (especially if one attempts to create an enterprise like app). You have cold fusion background whereas I have Oracle ERP background (and DARE to envision much can be acomplished using DNN for similar ERP like functionality).

Suggesstion, why don't we make it as a seperate (a fresh thread) to this forum with some subject "ERP Like custom module" to get feedback over it. This is important.

If LAMP techies can come up with hundreds of enterpise like OSS apps like SugarCRM, compeire, etc. etc. why can't WE using DNN? and effective DAL is one of the many important tech. foundations one needs to consider.

Regards

Alex

I am working on a suite of modules that all share one DAL. My reasoning behind this is some of my modules need info from other modules that are related. I didn't want to have dependencies on multiple other modules data layers so I chose this approach. The only gotcha I have had is sometimes Visual Studio likes to lock the main DLL. Changing to debug, then back to release mode fixes this though. Other then that, I have not had any issues with this approach. Currently there is 20 modules using this main DAL.

Dave

We are also starting down this path with our architecture.  Being more SOA based, we have more options when it comes to one, many, or a combination of both.  The reality of the situation in our realm is we typically deal with one significant object type per customer, say a loan application.  That loan application class would have all sorts of properties of various custom types, like a borrower, or if a home mortgage, a seller, or if a student loan a school.

Our "DAL" is multi-faceted.  From a DNN perspective, we're currently considering a common Web Service data provider which wraps the calls the UI would need to make to the web service, as well as the web reference to the web service.  The UI would call into the Web Service data provider, which would call the web service, which has its own DAL and assorted classes for working with and storing data.

So to visualize, it'd go something like....

DNN

----- Custom Module

----------Web Service Data Provider

---------------- Web Service

---------------------- DAL and Class Library

----------------------------- SQL Server / Data

Hope this helps.  You've got some good thoughts there to get you on your way.  I hope this example of an outside-of-the-box model gives you some perspective on the possibilities.

-Bill

Bill,

I would be interested in hearing of the preformance of this approach. I have also thought of trying an idea like this for some things, but time has keep me from trying this out.

Dave