Programming in "layers" [ASP.NET MVC]

[imaginekitty]

I've been reading up on MVC and I'm starting to get it but there are some ideas that are still foreign to me. When it is said that a programming layer is beneath another layer how is that defined? Are certain layers inherently above or below others? Is it purely conceptual or is it based on a defined architecture?

[Serenarules]

I'm not so sure now that I'm the one the should be commenting on this, as I've had some resurgence of self-questioning lately, but I'll give you the run down, from top to bottom:

Web / UI Layer: the mvc app
- Some people actually move controllers to it's own class library as well.

Presentation Layer: these are thin classes designed to package data for sending to views.

Logistics Layer: service interfaces and implementations, specification pattern objects, etc
- Define anything here that your app will use to apply logic or processing to data before sending it to the persistence layer.

Persistence Layer: repository implementations
- This defines how your data actually gets stored. It could be sql, linq, whatever. It could be MySql, Oracle, whatever.

Domain Layer: entities, value objects, and repository interfaces
- This defines the look of you app without defining how certain things get done.

Where you put things like extension method classes, custom controllers and other things is up to you. Really, where ANYTHING goes, organizationally speaking, is up to you. You can plop it all right into MyProject.models and it'll still be right as long as you keep things correct conceptually.

Short answer: it's a conceptual thing, but good physical organization helps in maintaining that.

[imaginekitty]

Thanks, man! Exactly what I was looking for.

[NightStalker-DNS]

I agree with Seren, explained very well. I would just swop the persistance and domain layer around on your list. lol. That has nothing to do with you app, just to read in the list. lol.

At the end of the day it is up to you and how far you want to go with layering. Sometimes if I am really in a hurry with ridiculous deadlines, etc. I only have 2 layers. Presention/UI layer in 1 and Domain/Persistence layer in another.

[imaginekitty]

Trying out MVC is making me think more clearly in at least these three layers. Some of it makes me think "that makes complete sense" and some of it makes me want to smash my head on the floor.

I know what you're saying about deadlines, too. I've put out a quickie before and then felt bad and went back to refactor but not to the level that MVC seems to want.

I think I shouldn't have waited so long to get into it.

[NightStalker-DNS]

I have a sorta love hate relationship with MVC. I love it, with regards to the way its put together and so forth, but hate it coz it feels like a step back in time from asp.net websites. No code behind, no databinding of server side controls. The not code behind is good, as it forces you to stick to strict standards, but its the lack of databinding that i miss. lol

[Serenarules]

At first, I would've agreed with you completely, but the more I worked with MVC, the more I realised that with the right patterns in place, the methodologies and conventions are just as strict. The practice that convinced me to use MVC over WebForms (and therefore codebehind) is separation of concerns. The MVC framework, and it's related patterns, promotes separation of concerns and makes the final code more readable and testable. Please note that these same practices can be used in a webforms app, however, you are still left with a mixture of logic and presentation, which some argue is a bad idea. Of course, this up to each person to determine. I've always had the "do what works" attitude.

[NightStalker-DNS]

Yea, that what I said. MVC is more strict and has great structure. Thats why I like it. The only thing I do not like is no Repeater, gridview, etc. But you are right. The code behind does almost promote mixing of the UI and Business layer

[Serenarules]

Oops, I think I read your previous post too quickly and missunderstood. Ah well. have you looked into partials? I am going to assume you have as you're pretty well versed. Is there any reason you would prefer a data bound control over using a RenderPartials(string partialName, IEnumerable models) method?

[dhtmlgod]

I think of "layers" in a Mvc application in a different way than I did with WebForms. This blog post sums up how I approach it: http://jeffreypalermo.com/blog/the-o...ecture-part-1/

[Serenarules]

One thing you'll want to ask yourself too is: if I were to hand these libraries over to another team, and they decide to build a different persistence layer, or a different ui, would they be able to simply swap it out?

I usually build my domain entities and persistence interfaces into an assembly of it's own, my mapping and persistence implementations into it's own as well, and in addition, any application services get their own layer. The reason is so that any one of them can be swapped, based on the fact that any replacements will be based on the same interfaces. So if a user doesn't like my linq to sql implementation, they can swap it out for an sql client based one, or one that hits an oracle db.

[imaginekitty]

Originally Posted by dhtmlgod

I think of "layers" in a Mvc application in a different way than I did with WebForms. This blog post sums up how I approach it: http://jeffreypalermo.com/blog/the-o...ecture-part-1/

That's given me much to think about.

Here is another mention of "web site size":

... This architecture is not appropriate for small websites. ...

Just as I've asked in the past about Entity Framework vs. Linq to Sql, how do you define the size of a web site? What is large and what is small??

[NightStalker-DNS]

Originally Posted by Serenarules

Oops, I think I read your previous post too quickly and missunderstood. Ah well. have you looked into partials? I am going to assume you have as you're pretty well versed. Is there any reason you would prefer a data bound control over using a RenderPartials(string partialName, IEnumerable models) method?

Yea, I have looked at that, and it is great, i just prefer the databinding way of doing it. Just guess some old habits die hard. lol

Originally Posted by NAWA-mark

Just as I've asked in the past about Entity Framework vs. Linq to Sql, how do you define the size of a web site? What is large and what is small??

A small website is anything 800px wide or less and big site above that. hahaha. Sorry, couldnt help myself.

Well, it will basically come down to your own discretion. Of how complex and how man facets your website will have. Are you going to take more time building the layers than the entire site? It is very hard to give a definitive answer to this.

I also have done many a project, where I receive a brief. Very simple site, so use simple tech. Only to have it evolve into something so much more.

[imaginekitty]

Originally Posted by NightStalker-DNS

... I also have done many a project, where I receive a brief. Very simple site, so use simple tech. Only to have it evolve into something so much more.

That's just it, it always turns into more than intended.