This question already has answers here:
Closed 11 years ago.
Possible Duplicate:
A modern n-layer asp.net web application sample?
I'm having a hard time trying to design a solid N-Tier framework in ASP.Net. I know the basic fundementals: BLL, DAL, and Business Objects, etc. What I can't understand is the actual flow of the application and what the return types in the BLL and DAL should be.
Most articles I've read have suggested that the BLL and DAL communicate via Business Objects. However I don't see the real benefit if I have to instantiate the Business Object twice during each pass.
Does anyone have any links to good tutorials/sample applications that could guide me in the right direction?
Thanks
First, you must understand that tiers and layers are different things, although they are often confused. A layer is a software abstraction. the L in DAL stands for Layer. The last L in BLL stands for Layer.
A tier is a physical seperation of some type. At the loosest definition, merely putting you DAL in a seperate assembly is considered a Tier, although I am a bit more narrow in my definition. I consider a tier to be a physically seperated component that does not require being run on the same computer (although it may run on it, it doesn't need to).
To answer your question, though. Yes, Business Objects are typically used to transfer data (also called Data Transfer Objects, or DTO's). I'm not sure what you mean by having to instantiate the object twice. Can you be more specific?
Don't know if you've already run into this article on msdn. If not it could be worth reading as they discuss designing tiers in general and DAL in particular, differences, pros and cons of different approaches. I think they use the same terminology as you do. Designing Data Tier Components and Passing Data Through Tiers
You could be also interested in answers to the similar question here.
Related
I am trying to make a website in ASP.NET MVC, but I am not really sure how I should organize things. N-Tier applications seem to work nice, but since I am a beginner programmer it is pretty hard to understand. I just want to create a small web application where people can login and create pages. In these pages they can add others things. The database won’t be bigger than 10 tables I think. Even though it is a small application, I would like to use some best practices that N-Tier applications use.
Is this a good approach? Or is it very wrong? :
Project.Models
Models that represent the entities in my database.
Project.DAL
Interfaces and implementations for my repositories and unit of work. Also my NHibernate mappings.
Project.BLL
Interfaces and implementations for my services.
Project.UI.Web.MVC
My controllers, viewmodels and views. The controllers get data from services and pass data (viewmodels) to views so I think it’s part of the UI.
There are no hard and fast rules about how to organise your project.
That looks pretty logical to me and seems to follow a lot of hte examples that i have seen across the internet.
All that matters is that its logical to you and your team in my opinion.
Take a look at this link as well, might be a lot of useful information for you there:
Best practices for MVC architecture
That sounds like a neat layering.
Define clearly on what goes in DAL, BLL and Web.MVC. Because people can have difference in opinion in what goes into business logic and ui logic, I suggest to have a weekly review of what has went into each layers - to start with.
One suggestion is to call Project.UI.Web instead of Project.UI.Web.MVC.
I generally use IoC pattern in my projects which are most of the time ASP.net based. Are there any guidelines on how to structure the projects in a general 3 layered project UI+BL+Data Access. I want to know more about how the folders should be created, where should constants be kept at within each layer (I keep all the strings such as query string parameters, stored procedure parameter etc in file named Constants which is singleton). How should I create classes that interact with Data Access layer from Business Layer etc. and all such code structure questions.
Is there any guidance or a book on this?
Microsoft has a plethora of information on this. I've used Microsoft .NET: Architecting Applications for the Enterprise as my bible for software architecture
http://www.amazon.com/Microsoft%C2%AE-NET-Architecting-Applications-Pro-Developer/dp/073562609X
Check out this MSDN guide as well
http://msdn.microsoft.com/en-us/library/ff647095.aspx
Also, take a look at some application frameworks like Sharp Architecture for examples
http://sharparchitecture.net/
A lot of NHibernate tutorials demonstrate software design principles that can be applied to any solution
http://nhforge.org/blogs/nhibernate/archive/2010/04/25/first-three-nhibernate-quickstart-tutorials-available.aspx
#robbymurphy has a great answer. I would only add that I keep most constants and interfaces in a separate project/assembly altogether. I call this my "core" assembly and and define interfaces that allow me to pass data from the top of the stack to the bottom without tightly coupling them.
It is not so much where they are used, but for what purose. I once attended a seminar class where the instructor pounded "high cohesion, low coupling" into our heads, over and over.
Keep those things that, in the real world, belong together, together, but, reduce dependencies between object whenever possible.
This is a cohesion question as well as a coupling issue: if the constants are truly internal to a class, make them private static members (i.e. and internal state enum) . If they are truly internal to a project, create a class for them, and make them internal (a database specific constant in your data layer). Otherwise, put them in a public class in their own project.
I recently worked at HP doing several ASP.NET MVC3 projects as I came from a software background I was relatively new to the inner workings of MVC3 as well as the best practices.
During this time I somewhat adapted the coding style of fellow co-workers and ways of designing my pages that I still stick with to this day. With all of this in mind my main question is what would anyone recommend for learning material; books/videos/tutorials. I can learn from any of those resources and I would love to know that I am coding properly.
I have several projects under my belt and many large scale business solutions that I have coded using Razor and ASP.NET but there are times where I feel that what I am doing is either very hacky or just an inefficient way of coding things. The larger the project is the more difficult it becomes to add new features because of this.
I think this is my lack of experience in coding but at the same time I would like to overcome this and I feel that with the mass experience I do have with MVC3 I could adapt to a easier style or design pattern that would help me not only optimize my code but become a much better web developer. If anyone has any suggestions on books or training sites or anything please let me know as I would love to get better.
Thanks in advance to anyone that has been in my shoes and is willing or capable of recommending anything!
I was dealing with the same issue and found it useful to make a mind map. While it's impossible to give you a full understanding, I can try point you in the right direction with some basic ideas.
download/view (http://www.xmind.net/share/highroad/mvc3-design-pattern/)
Are you familiar with design patterns? Well they exists with MVC applications too :)
If you want to talk the talk and understand what people including myself are talking about, you would need to know the typical design patterns that come with building what they call enterprise level applications. These design patterns are the only real way to begin to understand the concepts.
These patterns structure complex business logic in ways that have become the tried and tested solutions (design patterns) to the design challenges the developer's face.
In the diagram notice there are 3 main layers:
Presentation Layer
Business Logic Layer
Data Access Layer
Some of the highly used design patterns when dealing with Model View Controller in ASP.NET include:
Business Logic Layer Design Patterns:
Active Record. Models relate exactly to the database like in lightweight frameworks e.g. Ruby on Rails). When creating new MVC3 application with ASP.NET and scaffolding views and controllers, this is how it sets it up. Is perfect for less complex applications. So why not just use Ruby on Rails? I would
Domain Logic Layer. Uses MVC with the controller containing very little code and create lots of extra models that can do complex logic, the MVC is only for presentation. Often with this style of layer, a lightweight layer called a Service Layer can be used to call all the functions in the Domain Layer from the controllers i.e. the controller calls the method in the Service Layer class which calls the domain layer. This design pattern seems to be very popular with people who enjoy object oriented programming. See link below to my (quite basic) project designed using Domain layer.
Transaction Script - Use the controller to do a lot of the logic work per action, the problem is a lot of actions need to do the same things so there will be code repetition
For the Data Access Layer:
Something like entity framework models combined with a repository which can perform any SQL queries you need.
Not going into all the patterns for this layer but they include: Data Mapper
With simple apps, there is no real data access layer, it only becomes necessary if you use the Domain Layer in the business layer (which usually is the case)
Depending on what structure your application takes, your Models will mean very different things. In general they will not be models linked to the database (the default when creating a new app makes them like this). Instead they will be ViewModels which are only responsible for holding data that each of the views will need.
I have created a ssample app which you can see here.
https://github.com/testbrian/enterpriseframeworksB
I don't know if this is an example of an enterprise solution, but I have learned a lot from the techniques found in RaccoonBlog. I like how the Layout.cshtml and other razor files use RenderAction to modularize the views.
The project is an example of MVC3 using RavenDb, but it's also one of the best real world applications I've seen since it's actually used in production.
Hope this helps.
From last few days i have been searching the optimal architecture for my new web application, which would be devloped in ASP.Net using C#. Until now, i only find and study following 3
Three Tier Architecture (Note: By
Tier i mean logical layer)
Model View Controller (MVC)
Model View Presenter (MVP)
Now folling are my questions:
1) As far as i understand 3 Tier Architecture and MVP can I say that MVP and 3 Tier are
the same thing? If not, then what is the difference bewtween both? (Note: I only find
the difference between MVC and MVP or MVC and 3 Tier Archi but no one adress the diff
between MVP and 3 Tier Archi)
2) I only discover above three architectural options, is there any other options
available too? (Note: Here i want only the options for overall architecture of web
application,like above 3)
From a software architecture perspective; we use terms because terms mean something. When you use a term like "3-tier", you should use it where it fits it's intended and understood meaning. All sorts of things could be deemed "3-tier" simply by virtue of having three discrete components of some sort. But, if you used that term to describe MVP, you'd be misleading the other person. Why not simply say "MVP"?
3-Tier generally refers to three physical tiers. And Wikipedia has a great article on it here.
With the associated diagram:
Neither MVP nor MVC exclude using these three physical tiers. In fact, simply coining your application as an "MVC" application (or "MVP") doesn't really clarify much anymore. For example, it could be MVC on the server side (as in ASP.NET MVC) or it could be MVC on the client side with Javascript, or both!
As far as your question about architectural options; the playing field is pretty wide-open. The choices you make typically depend on a number of factors which you should be collecting while you collect your application requirements.
Often times you must make a trade off between Scalability and Complexity. However, a number of new technologies are making this trade off negligible - and I'd advise anyone starting a new project to consider them seriously (some discussed below).
It's almost always best to have, physically, a dedicated data tier (SQL, Mongo, Azure, Amazon, take your pick), and a dedicated, scalable, logic tier (usually implemented these days as WCF services in .NET land).
Most times people join their website and logic tiers... but this doesn't have to be the case. Sometimes it makes sense to have a physical tier exclusively for web services which are only accessible by your web site tier. Again, it's all situation-dependent.
As far as logical layers go (within your logic tier) it's almost always best to have some sort of data access layer (DAL), an in-code model (whether implemented manually, or through something like LINQ-to-Entities), and a dedicated business logic layer.
More and more these days people seem to be falling back to classic HTML and Javascript (with the help of things like JQuery, Prototype, DOJO, etc.) and using REST/JSON to chat with web services for retrieving and displaying data on the client side. In this scenario you can have a full-blown application on the client side, and another full-blown application in your back end... each with their own implementations of the logical layers I described above.
Options are wide open.
My take on things:
3-tier is not the same as MVP/MVC.
Many folks interpret the "Model" as a very broad concept that could contain lots of behaviour (including domain logic). I don't. The model is what the view needs to render itself. Sometimes it may have behaviour but, once again, only for behaviour related to view rendering.
With MVP you have a 1-1 mapping between the View and the Presenter. Although conceptually you could have more in reality it probably won't turn out that way. The presenter is only concerned with mediating between other layers and the view.
With MVC there is in all probablity more than 1 view that the controller deals with since it is concerned with flow.
So MVC/MVP can be used together and are front-end related and are part of the n-tier architecture.
Hope that makes sense.
You will see in answers such as this What are MVP and MVC and what is the difference? That MVC and MVP are addressing the structure of the code concerned with UI. They address questions such as:
Which component understands the user's actions?
Which component decides what view to present next?
What is the relationship between View and Model?
Neither MVC nor MVP go into details of what's inside (or beneath) the Model. In some systems the Model is comparatively simple, just a thin skin on top of a database, in other systems there's an awful lot of logic down there, for example integration with Enterprise systems such as SAP and CICs.
In its traditional meaning a 3-tier architecture (or more generally an n-tier architecture) puts additional structure inside the Model.
This wikipedia article discusses MVC v n-tier architectures. I think it's reasonable to substitute MVP for MVC in this article.
As to your application's architecture: my perception is that modern apps tend to have a rich UI presented in the browser, using simple REST services supplied by a Model on some server and then some arbitrarily complex stuff in the model. I guess you can see this as an n-tier architecture. The interesting thing is that as you structure your Javascript (JQuery, Dojo or whatever) in teh browser you find design patterns coming out, and an MVC pattern actually can emerge purely in the presentation tier.
I'm working on a fairly large project at the moment and am currently in the planning stages. I've done a lot of reading into the various patterns suggested for development, somthing that has split the team at the moment is when using Entity Framework should the classes be passed through the applciation layers so that a view accepts an Entity Framework class or should these classes be mapped to BLL Classes and if so at which point (Controller or Library) should this be done?
I'm interested in hearing some positives and negitives for each solutions.
This is one of those great "it depends" questions ....
For me it's a matter of pragmatism. I use the raw entity classes where ever I can for expediency. I start using DTOs when either the object graph in question starts becoming too cumbersome or the object in question has sensitive data I don't want sent over the wire.
This is again one of those questions that doesn't really have a right or wrong answer, its personal taste really. Personally I would opt for using DTO's or interfaces when passing data to the Views. I don't tend to pass around entity objects to different layers of my application they are strictly confined to the DAL, or if I do need to pass it up a layer I would almost always use an interface never the concrete type.