views:

129

answers:

4

Hi,

I am a asp.net developer and don't know much about patterns and architecture. I will very thankful if you can please guide me here.

In my web applications I use 4 layers.

  1. Web site project (having web forms + code behind cs files, user controls + code behind cs files, master pages + code behind cs files)

  2. CustomTypesLayer a class library (having custom types, enumerations, DTOs, constructers, get, set and validations)

  3. BusinessLogicLayer a class library (having all business logic, rules and all calls to DAL functions)

  4. DataAccessLayer a class library( having just classes communicating to database.)

-My user interface just calls BusinessLogicLayer. BusinessLogicLayer do proecessign in it self and for data it calls DataAccessLayer funtions.

-Web forms do not calls directly DAL.

-CustomTypesLayer is shared by all layers.

Please guide me is this approach a pattern ? I though it may be MVC or MVP but pages have there code behind files as well which are confusing me.

If it is no patren is it near to some patren ? pleaes guide

thanks

+2  A: 

That's not four layers, that's three layers, so it's a regular three tier architecture.

The CustomTypesLayer is not a layer at all. If it was, the user interface would only use the custom types layer and never talk to the business layer directly, and the data access layer would never use the custom types layer.

The three tier architecture is a Multitier architecture

Guffa
+1  A: 

Take a look at the Entity Framework or LinqToSQL. They can both generate your data access layer automatically from your database. This will save you a lot of (boring) work and allow you to concentrate on the interesting layers.

Code-behind does not really have anything to do with architecture - it is more of a coding style. It is a way of separating code and content. Any architecture you mention can be used with or without code-behind.

You seem to be describing a standard three-tier architecture. MVC is a pattern than describes how your layers and the user interact. The user requests a page (represented by a View), which requests its data from the Controller. The Controller communicates with your business layer (Model) to extract the correct data and passes it to your View for display. If the View is interactive, for instance it allows the user to update something, then this user action action is passed back to your Controller, which would call the relevant method against the business layer to save the update to the database.

Hope this helps.

Mikey Cee
Thanks Mikey for such nice reply but please I have 2 connecting questions here, I hope you will guide on this.1. Entity Framework and LinqToSQL which one is better and even in Linq is LinqToSQL best to use ?2. What would be layering by using Entity Framework or Linq ?thanks
haansi
Take a look at this question for opinions from people far more knowledgeable than me... http://stackoverflow.com/questions/8676/entity-framework-vs-linq-to-sqlIn summary, LinqToSQL is a quick (and perhaps dirty) approach, whereas EF is a vast, all-encompassing ORM that introduces the Entity as new layer of abstraction. It's incredibly powerful but can also be a intimidating. Whichever you choose, you can still use LINQ statements in your queries.Some people say that LinqToSQL is dead and the future lies in the EF. It does appear that EF can do everything that LinqToSQL can do, and more.
Mikey Cee
+2  A: 

As far as patterns go, I recommend getting to grips with these:

  • My biggets favourite by a mile is the Dependency Inversion Principle (DIP), also commonly known as (or at least very similar to) Inversion of control (IoC) ans Dependencey Injection; they are quite popular so you should have no problem finding out more info - getting examples. It's really good for abstracting out data access implementations behind interfaces.
  • Lazy Load is also useful. Interestingly, sometimes you actually might want to do the opposite - get all the data you need in one big bang.
  • Factory pattern is a very well known one - for good reason.
  • Facade pattern has also helped me keep out of trouble.

Wikipedia has a pretty good list of Software design patterns, assuming you haven't seen it yet.

A final thing to keep in mind is that there are three basic types of patterns (plus a fourth category for multi-threaded / concurrency); it can help just to know about these categories and to bear them in mind when you're doing something of that nature, they are:

  • Creational
  • Structural
  • Behavioral
Adrian K
+2  A: 

Scot Hanselman has a good article on this which is a must read.

CodeToGlory
hi CodeToGlory,I read this article, it was nice thanks for sharing it. But Scot did not comment where server side data validations should be placed in code behind .cs file, in business entity or in business logic layer ? Can you please guide. Secondly in diagram he shows Security, operations Management and Communication layers he did not mention about these in article. Please guide on this.
haansi