DAL Considerations

May 11, 2008 at 7:23 AM
I just had time to check the schema out.
I have a few comments but in general it looks good and I would like to get started on the DAL.

How about going the way Rob Conery does in his MVC Storfront screencasts with a repository that returns IQueryable<T> and then filter extension methods and then a spike?
It looks like a pretty solid design.



My schema comments:

Comment Table:
     Email should be larger than 50 with large domain names out there and some corporate email addresses I don't think emails should b elimited to only 50
     Why is approved nullable, shouldn't it be set to true if comments are unmoderated and false if they are

Page Table:
       I think we should have nullable keywords and description fields
Coordinator
May 11, 2008 at 4:38 PM
Edited May 11, 2008 at 5:37 PM
I'm not actually done with it.. I just wanted to upload that to get the nVARCHARs up. I'm trying to keep this one relatively simple with a few scalar functions, a few table functions, and simple insert procs that return 1 for success or 0 for failure.

[I don't think I've uploaded this yet]
I'm not familure with the IQueryable<T> approach but here is what I was thinking:
Every page has a path, for example: "" would be the root page, "/About/Policies" would be the page "Policies" which is a child of the page "About". Each page also has an action, for example "page", "blog", etc etc. So during the route check, we would use a catchall passing that value to the function which determines if it is valid. The function then returns either the ID of the page and the action or -1 and 404. If the page is valid, the action method is called with the ID of the page. There will need to be routes prior to the catchall for things that will have variables. For instance, a shopping cart would need to have a catch that easily handles the product ID and the action... actually it may not..

>>>     Email should be larger than 50 with large domain names out there and some corporate email addresses I don't think emails should b elimited
 >>>     to only 50
Sorry, this must have happened when I switched it over to nvarchar. Fixed

>>>     Why is approved nullable, shouldn't it be set to true if comments are unmoderated and false if they are
Good point, not sure what I was thinking there..

>>>       I think  should have nullable keywords and description fields
The reason I left keywords as a non-nullable was I figured that there would be default keywords that are always inserted. After thinking about it I agree with you on both accounts though. I'll upload it once I'm finished with the insert procs which should be in a little bit.
May 11, 2008 at 5:32 PM
Your design sounds good.

What methods should the DAL implement to enable your design.

Although the schema will be evolving there is no reason not to start the DAL right away. That's one of the ideas of the repository pattern, All the data access gets done from one place so the controllers don't care if the DB gets changed.

If you know what methods you would want to call from the controller I can  start implementing them
Coordinator
May 11, 2008 at 5:38 PM
Honestly, it sounds like you know more about DAL then I do. Just let me know what you need and I'll get it done.
May 11, 2008 at 9:15 PM


ChanceUSC wrote:
Honestly, it sounds like you know more about DAL then I do. Just let me know what you need and I'll get it done.

Actualy I wouldn't consider myself a DAL expert, but I can try.

Ill start with the basic functionality that would be needed to make the controller action you described.
Coordinator
May 11, 2008 at 11:49 PM
Sorry this coming a little later then I wanted. My house's break box kept tripping and I also had grilling duties for mothers day.

UPDATE:

1.    The insert stored procs are done. I actually went back and removed the scalar return after speaking with a few different DBAs. They all advised that it is better to catch an exception then to return a scalar.

2.   A few minor changes were made to the schema. They were either things that I neglected on the first run through and I caught or minor changes to improve things.

I want to actually go back and change the nvarchars to varchars where it makes sense but for now I think I am going to hold off.
Coordinator
May 11, 2008 at 11:51 PM
I wrote a simple function that returns a table containing the ID and the action. The name of the function is fn_GetPage with the values page_id and page_action

srulyt wrote:


ChanceUSC wrote:
Honestly, it sounds like you know more about DAL then I do. Just let me know what you need and I'll get it done.

Actualy I wouldn't consider myself a DAL expert, but I can try.

Ill start with the basic functionality that would be needed to make the controller action you described.


May 12, 2008 at 10:45 PM
I changed the directory structure and added test projects. NUnit and MSTest are very similar so I made both projects and those more comfortable in one or the other can use the one they want and then we can port the tests.

I put the project one level deeper so we can add readme, help and license files at the top level.

I should have some time to work on this tomorrow.

Good night for now
Coordinator
May 13, 2008 at 5:53 AM
bah I added commit to all the SPs and didnt notice.. sorry was stuck in the Oracle mindframe. There was a slight issue 1 of the functions as well, but I fixed that so I'll change all the procs first thing in the morning and upload the fix.. sorry bout that.
May 13, 2008 at 9:34 AM
Does the action change the flow of the program, or is the flow the same (get the page from DB, render view) for all pages and the action just decides which view to render?

If the latter is the case there is no reason to get the page action until the page data is loaded.

So instead of a function that gets the ID and the action all you need is to get the ID and after you load the page you could check the action before you render the view.
May 13, 2008 at 9:55 AM
I just added a Data project with a proposed IPageRepository.

Check it out, see if makes any sense or if you would want it done another way.

Read the comments
Coordinator
May 13, 2008 at 1:32 PM
Edited May 13, 2008 at 1:38 PM


srulyt wrote:
Does the action change the flow of the program, or is the flow the same (get the page from DB, render view) for all pages and the action just decides which view to render?

If the latter is the case there is no reason to get the page action until the page data is loaded.

So instead of a function that gets the ID and the action all you need is to get the ID and after you load the page you could check the action before you render the view.

Here is what I was thinking, if you don't like this idea we can go another route.

Lets say that you have a site with standard pages and .. a blog. Since a blog 'post' is nothing but a page with a different style and a collection of comments it could reside within the Page table. In order to this it would need at least a unique action so that we aren't having to do the checks within the style.

Rather than having www.website.com/home/about for your page and www.website.com/blog/some-blog-entry what you could do is use a catchall. That way, you'd snag "/about" pass it to the DB and get both the id and the action. From there you could call the appropriate method for the correct page.
Coordinator
May 13, 2008 at 3:18 PM
For the love of god Team Explorer is pissing me off. The DB has apparently been assigned $/MVCMS/App_Data as its location even though I've changed my workspace to $\MVCMS\MVCMS. I've downloaded your source and simply replaced the DB but it is all screwed up now.

Any idea on how to fix this?
May 13, 2008 at 7:51 PM
First delete the files from your local HD. then go into the source control browser window and right clisk the MVCMS porject and select get specific version. In the dilaog select latest version from the dropdown and select the two check boxes on the bottom.

I had the same problem and thats how i fixed it. 
May 19, 2008 at 1:30 PM
I just uploaded a LinqToSql DAL with two methods that should let someone working on the controllers start working

GetPage(int ID) returns the page from the DB with the title, data, etc....

GetPageInfo(string Path) returns the action and the ID of the page based on the path

Let me know if this is what is needed.

I would like to continue implementing but I don't fully understand the schema. Please tell me what needs to be done and I can implement it.

I should have a nice amount of time in the next couple of weeks, but since I have never built a generic CMS before I am having trouble making the design decisions on my own.

Let me know more about what you have in mind for DAL, controllers, views, Logging, Authentication etc... and I can get a lot of it done
Coordinator
May 19, 2008 at 1:51 PM
Bah got a bad header when I tried to respond earlier.. I just uploaded a release about the same time as you so ours aren't merged. I was trying to get a very rough draft (core concepts) of the management system so I haven't implemented the DAL, validation, etc yet. I will merge our code when I get back from a meeting that I am about to be late too hehe.

If you are on later and are working on this.. I'll be in #mvcms on efnet if you'd like to talk realtime
May 19, 2008 at 3:55 PM
The changes i submitted are merged into your release.

I see you started with some controllers and actions.

Let me know what info you need from the DB and ill make it accessible in a better way than accessing directly from the DataContext.


BTW what server do i need to connect to to chat with you.
Coordinator
May 19, 2008 at 6:34 PM
Bah got a bad header when I tried to respond earlier.. I just uploaded a release about the same time as you so ours aren't merged. I was trying to get a very rough draft (core concepts) of the management system so I haven't implemented the DAL, validation, etc yet. I will merge our code when I get back from a meeting that I am about to be late too hehe.

If you are on later and are working on this.. I'll be in #mvcms on efnet if you'd like to talk realtime
Coordinator
May 19, 2008 at 7:45 PM
Fellas, I was looking at the source code just now, having a hard time understanding the 'big picture' of how our data model is going to piece things together.  I get the page stuff, and maybe I'm missing something, but is there a plan in mind right now for how we're doing templating, storing partial pages (e.g. user control style widgets), etc?  I recognize that a lot is in the air at this point, just wondering if you guys (since you're workign data model) had a rough plan already?

Thanks,
Paul
Coordinator
May 19, 2008 at 8:35 PM


pvencill wrote:
Fellas, I was looking at the source code just now, having a hard time understanding the 'big picture' of how our data model is going to piece things together.  I get the page stuff, and maybe I'm missing something, but is there a plan in mind right now for how we're doing templating, storing partial pages (e.g. user control style widgets), etc?  I recognize that a lot is in the air at this point, just wondering if you guys (since you're workign data model) had a rough plan already?

Thanks,
Paul

As much as I want templating, I want to get something 'out' and refractor later. The reason I say this is I would personally like to draw people back to the project. The three of us could build a really solid CMS but I think it would take much longer than if we released 'something', got people back, and went back to the drawing board from there.

First, if you downloaded my source you didn't get Sruly's DAL which I am going to go back and piece in in just a moment. Unfortunately we released what we had at about the same time this morning. To answer your question though, there are many different ways that we can incorporate contemplating.. I would really like to shop around for a view engine or write one out specifically for writing out templates and I would like drag / drop for links, images, and components for content/template building (which should be fairly simple.. its just a trigger on the tree event but I *suck* at js). In terms of air - I tried to post this earlier today but got a bad header and then had to run to a meeting so I didn't get a chance to revisit it in my quick post above. My release is an *extremely* rough draft of what I want.. I didn't implement anything other than a few concepts - theres still a ton of coding that needs to go into it there. Once I get the concepts down I'll go back and polish it out.

If you'd like to talk - join me on IRC in #MVCMS (efnet server)
Coordinator
May 20, 2008 at 3:19 AM
well, you hit it on the head; getting the basic features down first is best, we can come back and add dhtml hotness once we have the solid foundations.  I don't see a good reason to start baking it in at the beginning.  I was thinking more about how to start a sample view; I assumed that rather than shopping for a custom engine we'd just start with the default (webforms) one. 

Maybe it's poor understanding on my part, but I'd assumed what we were going for here (for 1.0 at least) was a really basic implementation using mostly out-of-the-box stuff, limit on the 3rd party add-ins, no?
May 20, 2008 at 10:09 AM

right now the idea is to get something that works with the most basic CMS features released.

We can refactor and add features later.

In regard to templates and views I think we should use the webforms view engine with master pages for templates. No widgets or controls in version 1

The data model is to have multiple repositories (linq, xml) and for them to be configurable in the web.config. To do this we need a Data project with the interfaces and the implementations and a service project that gets the configuration from the web.config. Then the models access the service and are repository agnostic.

In version 1 I think 1 repository (linq) is enough but in the future we can allow for 3rd party repositories.

The repository/service/model pattern will allow for a great amount of scalability and customization. In the future the service layer can be WCF allowing for remote deployment without any extra hassle

Coordinator
May 20, 2008 at 3:13 PM
Edited May 20, 2008 at 3:31 PM



pvencil wrote:
well, you hit it on the head; getting the basic features down first is best, we can come back and add dhtml hotness once we have the solid foundations.  I don't see a good reason to start baking it in at the beginning.  I was thinking more about how to start a sample view; I assumed that rather than shopping for a custom engine we'd just start with the default (webforms) one.

Thats the idea for the first release, when I said shopping for a new view - I meant for future releases after we refractor.



pvencil wrote:
Maybe it's poor understanding on my part, but I'd assumed what we were going for here (for 1.0 at least) was a really basic implementation using mostly out-of-the-box stuff, limit on the 3rd party add-ins, no?

Define 3rd party add-ins.. do you mean things such as ExtJS and other add-ins to Asp.net / MVC because I've used extjs & a package for linq to JSON




srulyt wrote:

right now the idea is to get something that works with the most basic CMS features released.

We can refactor and add features later.

In regard to templates and views I think we should use the webforms view engine with master pages for templates. No widgets or controls in version 1

The data model is to have multiple repositories (linq, xml) and for them to be configurable in the web.config. To do this we need a Data project with the interfaces and the implementations and a service project that gets the configuration from the web.config. Then the models access the service and are repository agnostic.

In version 1 I think 1 repository (linq) is enough but in the future we can allow for 3rd party repositories.

The repository/service/model pattern will allow for a great amount of scalability and customization. In the future the service layer can be WCF allowing for remote deployment without any extra hassle


What he said? hehe glad you are still around srulyt
Coordinator
May 21, 2008 at 2:42 PM

Ok, glad srulyt brought it up, I was going to ask about going with a domain driven design here anyway.  I saw a lot of early motion toward building the DB first and then a DAL and was thinking we need to be careful not to hem ourselves in.

Re: 3rd party; I'm ok using ext-js or jquery as I stated before, I would prefer to keep the server-side code as close to 'pure' MS MVC Framework as possible; my point was I didn't want to start introducing a lot of dependencies right away; add as needed.

So, can we define the v1.0 features that we consider 'core'?  I don't think I've seen that anywhere on here yet, at least not in an organized fashion.  I'll start:

1.  Default template (master page) which can be replaced / customized by developers and pushed down via configuration changes (in other words, we don't hard-code master page names in the content pages; set it in the web.config)

2.  Membership API (might adopt the other guy's, might not; should be pluggable) to manage users, roles, and rights.

3.  Users of the appropriate rights level (configurable) can create new pages

4.  Users of the appropriate rights level (configurable) can edit existing pages

5.  Pages can be tagged and can also be structured in formal category / subcategory patterns with infinite depth (a subcat is nothing more than a cat w/ a parent category)

6.  Searching

7.  Document / media storage and serving.  User rights?  Version control?  check in / check out?

8.  Stylesheets used exclusively for all presentation.  Do we need to adopt or create a 'theme' feature that lets stylesheets be set in web.config?  Probably 1.0 just use the StyleSheetTheme property, contemplate refactoring if need be.

9.  Menus can be configured / edited as needed by users of appropriate rights

10.  URLs can be mapped as needed by users of appropriate rights (may be limited based on Win Server version / external components e.g. ISAPI_Rewrite)

Ok, so that's my top ten.  

May 23, 2008 at 8:38 PM
Great set of starter features.

Have you thought about how the "published" pages get invoked? IE - what's the navigation structure.

I wrote a "slugify" method that replaces spaces with a dash and removes other "unwanted" characters to make a url freindly page name.

Eg. A page name of "Site Documents" would become "site-documents", and referenced in the url as .../pages/site-documents

If that page had subpages, the url would be .../pages/site-documents/accounting

Etc. this is opposed to .../pages/12/3

Why? SEO - google would index the former easier than the later.

Has anyone thought about url structure? I'm sure they have - do we have a features list?
Coordinator
May 24, 2008 at 4:41 AM
Yeah, ChanceUSC posted this on the Routing thread, and we agree on the keyword-based urls.   I don't know of any features list other than what I posted above, though, so feel free to add/expand/whatever. Just realize that we're trying for a 1.0 that's relatively light and easy and quick to code, esp. since we have a fairly small team at this point.