| Author |
 Topic  |
|
kentk
Starting Member
USA
30 Posts |
 Posted - 24 May 2006 : 15:21:33
|
Would it be safe to say then we would like to support any databases that are ODBC, OLEDBD compliant or have a .NET provider. Or do you go by the SQL standard they support? Or am I over analyzing this thing?
For instance the db HuwR recomended Firebird SQL does have a .NET provider how do we account for that in this model? I know we want to keep this a generic as possible but I was kinda wondering on the datalayer if we should not have seperate classes for each type of db Access, SQL, MySQL that way if some want to support a different db they can just add a class to the project. That way if there are certain optimizations or other features that other db's have they can be included without interfering with the core, you would include that in the db's individual class.
You would still pass your dataset, readers, updates ect to the UI the same way.
Does anything I just said make sense I think were all headed toward the same goal. |
Kent
"Wakey, wakey, hands off snakey!" |
 |
|
|
GwynneR
Starting Member
7 Posts |
Posted - 24 May 2006 : 16:47:08
|
quote:
Originally posted by kentk
Would it be safe to say then we would like to support any databases that are ODBC, OLEDBD compliant or have a .NET provider. Or do you go by the SQL standard they support?
If you go the provider route, you don't have to worry about any of that as it get's offloaded to the concrete implementation of each provider, so for example, once the base classes are written anyone can come along and write a MSSQLMembershipProvider, a MySQLMembershipProvider, a FireBirdMembershipProvider, a DNNMembershipProvider (uses the membership tables from DNN to feed Snitz), an XMLMembershipProvider. The abstract base class will look pretty much like the code that Ghostnetworks posted earlier and is just a bunch of functions that are called by the Snitz code, but which must be overridden by each concrete provider, regardless of what datastore it's working with. In essence providers are just like a plug and socket, as long as they fit each other correctly, ie all the functions are overidden correctly and returning the right data, the (.Net) Snitz code should just work with it.
Again, if you go down this route, you wouldn't just have a membership provider, it makes sense to split the db functions into specific logical chunks, membership, roles, forum (deals with posting etc) - this is just off the top of my head, haven't given it a great deal of thought.
quote:
I know we want to keep this a generic as possible but I was kinda wondering on the datalayer if we should not have seperate classes for each type of db Access, SQL, MySQL that way if some want to support a different db they can just add a class to the project.
Yes, as you can probably see from the first part of my reply, that's essentially what a concrete implementation of the provider does. It makes it trivial to interface new datastores to the backend code. All that's required is to implement the abstract class and it's functions and declare your new provider as the default in the web config file to use it.
*side note - MS's intentions for the provider model are much wider than what we're talking about here. It's designed to facilitate interfacing any two items where one end of the contract can have many different sources - think PrinterProvider etc. Once it dawns on you what they're getting at with it you realise it's such a stupidly simple concept it's amazing it's not been used before :)
Here's a couple more links about the provider model in general:
Flexible and Plug-in-based .NET Application using Provider Pattern
ViewState Provider - an implementation using Provider Model Design Pattern
|
Edited by - GwynneR on 24 May 2006 17:00:16 |
|
|
|
GwynneR
Starting Member
7 Posts |
Posted - 24 May 2006 : 18:17:26
|
quote:
Originally posted by GhostnetworksSomething tells me, I should have stuck to that little DB selector class I had in the beginning 
Sorry, shouldn't have stuck my oar in
Still somewhat unclear as to why there's a need to start out with 1.1, seems like all that will achieve is to increase the workload/complexity and I should probably 'fess up and say that I'm not totally sold that there's an overwhelming need for a .Net version of Snitz, it's remarkably easy to meld into a .Net application (1.1 or 2) as it is. That's not to say that I don't find it interetsing as an exersize though and as long as I don't get a slap round the head off Huw when I see him, I'll keep sticking my oar in  |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 24 May 2006 : 23:12:41
|
I'm sorry also Ghostnetworks if I am saying to much, just trying to follow your logic.
quote:
and I should probably 'fess up and say that I'm not totally sold that there's an overwhelming need for a .Net version of Snitz
There really isn't a need for a .NET version at all, I must confess that I want to learn ASP.NET from people like you and Ghostnetworks, you guys seem like you have real world experience. So maybe it is best for me to sit back and let you 2 roll with it, just know that if you want some one to code, I am willing to help. |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 24 May 2006 : 23:26:53
|
quote:
Originally posted by kentk
Would it be safe to say then we would like to support any databases that are ODBC, OLEDBD compliant or have a .NET provider. Or do you go by the SQL standard they support? Or am I over analyzing this thing?
For instance the db HuwR recomended Firebird SQL does have a .NET provider how do we account for that in this model?
ConnectionStrings.com is your friend.
If there's a connection for a DB in any platform, you'll find it there.
Of course we'll just need to focus on providers for the common ones first.
I think Firebird is very forgiving (MS Access ease) on the client-side, which will make it more fun than MySQL.
quote:
Originally posted by GwynneR
.. I should probably 'fess up and say that I'm not totally sold that there's an overwhelming need for a .Net version of Snitz
This is what nerds do, when their StarTrek DeepSpace9 DVD arrives late and need to do something while it's still in the mail.
That and being interested in a fully pluggable template set and forums.
Snitz being one of the first forums I've installed and customized, I thought it was a good place to start.
Of course, all this got sidelined for a while (work stuff) and I ended up having writing my own.
And I must fess up that I have a really, bad habit of jumping into write something before planning a project out completely.
If I have something to work with, I'm pretty good putting something together. Right now, I just need some direction on this.
As for starting with 1.1, there is still a large margin of users still on it. And there are a few web hosts that still don't offer it to older customers.
So I was thinking of keeping the CommunityServer method of supporting both platforms. |
 |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 25 May 2006 : 09:07:52
|
Actually this is what I do while waiting for George Lucas to change is mind about making more Star Wars movies. And Goofing off at work .
So when you guy are talking providers, I guess I'm getting kinda lost. Are you talking the data provider or the membership provider or both, the posts were kinda jumping around yesterday.
Could we start at a basic level and define what is going to go into the dataaccess layer - the classes and mods I mean.
So far from previous posts I see:
Data Access Layer:
database.vb Database independent connections, adapters and commands
config.vb Web.Config access class
methods.vb Returns Datasets, Readers, Tables etc..
Is the membership class also included in this layer? Would it be a seperate class or part of another?
Who besides the database is it talking to? Only the business logic layer or can it talk to the UI also? Do we want to allow it to talk directly to the UI or keep a strict model?
|
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 25 May 2006 : 09:51:52
|
Well, one kinda builds on the other.
Membership providers are just like Role providers in that they have abstract functions to add/delete/modify etc...
The actual execution of the SQL is left up to the Data provider.
The data provider is an abstract too.
Each DB provider inherits from the Provider Base.
Like MsAccessProvider, SQLDataProvider etc..
The idea is to have pluggable segments in the application so Membership and Database can be changed on the fly.
A little like changing an incandescent lightbulb into one of those florescent types to save electricity.
A user may decide to move to a different DB and can change the Data Provider.
There may be a need to merge the forums into the rest of the site (maybe it grew faster than expected), but the user still wants one platform and one group of users.
So the Membershp Provider can be changed.
...A single platform requirement is bound to come up, as was in my case where I disabled serving ASP pages and only allowed ASP.Net on my home server.
It was easier to manage the security stuff. Hence my need to move Snitz to .Net (couldn't get it done one time then).
We shouldn't look at individual Class (something.vb) files.
I know I wouldn't... I'd just get dizzy!
Instead we should look at the different layers as a whole for now.
The Class tree would probably go like this...
Data Access Layer
|- Data Provider
|- MsAccessProvider with DataSet/Reader/Table.. return/execute functions
|- MSSQLProvider with DataSet/Reader/Table.. return/execute functions
|- MySQLProvider with DataSet/Reader/Table.. return/execute functions
|- ...Anything else recommended
Business Logic
|- Membership Provider
| |- Core Forum Membership Provider (all the member functions in Snitz) with included security
| |- Optional Membership Provider the user can add at his/her leisure for site integration.
| |- Optional Role Provider for the same reasons... We may not need this for basic forum operations.
|
|- Security (Privileges can be taken care of in the Membership or Role Provider)
|- Admin/Mod functions
|- Maintenance functions
|- Post functions
|- Profile functions
Presentation Layer
|- Repeaters / DataGrids / Custom controls
|- Stylsheets / HTML / JavaScript
|- And of course, images
Boy, you weren't kidding when you said this was a big job
edit_
One thing that may or may not have been pointed out.
With each Data Provider, the actual database schema becomes irrevelant.
You could even have one DB for the users and another for the forums (though, that would be unusual). But that would be how a user with DNN or PHPNuke, for example will still be able to use Snitz as the forums with the same exact user base.
Hope that paints a clearer picture.
DataProvider connects directly to the database and gets.
MemberProvider uses DataProvider to get data.
Business Logic Layer connects to both to return/execute.
But each will get things done via the layer above it.
....Um... Obviously I stink at Haiku |
|
Edited by - Ghostnetworks on 25 May 2006 10:37:05 |
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 25 May 2006 : 12:19:24
|
So let me see if I am starting to see the light.
What you've been working on is a base provider that other providers will inherit. The base provider contains generic functions and methods to access the database and it's data. Once this is nailed down then we can proceed with making the providers for the default databases we are going to support ie. SQL Server, Access, MySQL.
For example: If I wanted to create a provider for database "X" I would inherit the base provider and then override the methods as needed and/or create additional method and functions.
Does this sound about right |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 25 May 2006 : 21:48:57
|
You got it!
The provider I was focusing on was actually the MSAccessMembershipProvider.
( Made up of all "Public Overrides Function Something.." )
For this to work, I would, of course have to write and extend the MembershipProvider abstract.
( Made up of all the overridable functions and properties )
But then I had issues with MembershipUser and UserCollection.
That's when GwynneR suggested I may be going about this too ridgidly.
We don't need to exactly duplicate what 2.0 does.
As in that implementation is very broad and a little overkill for Snitz. |
|
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 25 May 2006 : 23:03:58
|
Maybe we should reconsider keeping backwords compatability to the 1.1 framework, to help cut out some of the complexity it would add to the project. By the time this is ready to go live I have a feeling alot more people will have made the jump to 2.0. And also the way Mircrosoft is kicking out new versions of the framework I would hate to go to the trouble of keeping the backwards compatibility only to have another version of the framework released before we go live. Aren't there betas of the next version out there already. I have a gut feeling that the next version will be released faster than the time between 1.1 and 2.0.
What do you guys think? |
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 26 May 2006 : 23:41:06
|
Well, I can't make a decision for everyone.
But, I think it's still worth it to provide 1.1 compatibility, but if the general consensus is to move ahead with 2.0 only, then we'll do that. |
|
|
|
|
kentk
Starting Member
USA
30 Posts |
Posted - 27 May 2006 : 23:50:15
|
Ghostnetworks,
What do you see as the biggest challange to maintain backward compatibility with the 1.1 framework? I have only been working with 2.0 since November, so I don't know alot about what has changed or been added to ASP.NET. So far I have come across one issue, the email objects are now in a different namespace they used to be in system.web now they're in system.net. Not the end of the world, but a significant change to a few of the programs that I am working on at work.
Anybody else notice any significant changes in the common stuff they use or behavior changes from 1.1 to 2.0 framework?
Anybody else want to chime in on the framework we should support? Your opinion matters
|
Kent
"Wakey, wakey, hands off snakey!" |
|
|
|
Davio
Development Team Member
Jamaica
12217 Posts |
Posted - 28 May 2006 : 01:17:56
|
My opinion to the dilemma.
Make it 1.1 framework compatible. 1.1 framework is on majority of servers. 2.0 is still new. Not every server will be on the cutting edge of Microsoft's technology. |
Support Snitz Forums
|
|
|
|
Ghostnetworks
New Member
95 Posts |
Posted - 30 May 2006 : 04:20:19
|
Yeah this is what I thought too.
Though I host my own portal, my domain is hosted on JodoHost and they don't have 2.0 for older customers.
Users who want 2.0 need to move their sites to the 2003 servers and there's a small fee.
The challenge is keeping providers as with Membership and Roles.
In 2.0 the implementation is ridiculously simple since ProviderBase is included.
In 1.1... Not so simple, since code abstracts and functions for each of those abstracts need to be written.
The other option was to write our own, but GwynneR stuck an oar into that 
The thing is though, I do see his point on obsolescence, and hardcoding membership and role functionality is obsolete by 2.0.
I don't know how many users will actually merge Snitz with DNN or some other portal, but summarizing his posts...
"Why limit ourselves before we even write any code?"
As for the email object issue you pointed out, it is only a burden for existing applications. New code will have provisions to deal with this.
As for other significant changes, MSDN has a laundry list of potential problems and solutions.
Most may not apply to this project, but worth a good once over. |
|
|
|
|
HuwR
Forum Admin
United Kingdom
20579 Posts |
Posted - 30 May 2006 : 09:27:14
|
quote:
Though I host my own portal, my domain is hosted on JodoHost and they don't have 2.0 for older customers.
Users who want 2.0 need to move their sites to the 2003 servers and there's a small fee.
What motive can they possibly have for that other than to make money out of you, .net 2 does not require windows2003, it is a five minute install on any version of windows, so you are just being conned. |
|
|
|
Topic |
|
|
|
Topic Locked
