I have a asp.net project and Its in designing phase. Its about products and shops navigation system. Users can browse/search products. I want my web application to be extendable and flexible. What I initially planned was to make it an MVC and for database I propose ORM (Object Relational Mapping). Is that right? what could be the problems I face with this proposal. I am learning asp.net so I don't know much about the problems.What design do you people suggest?
It's great that you've decided to learn ASP.NET.
Regarding design approach, it sounds like your question is 2 part: a) MVC or traditional web forms ASP.NET, and b) ORM or no ORM.
a) Generally speaking, if you have a good programming background, I would recommend MVC over web forms for any consumer facing Internet product. It promotes testability, clear separation of concerns, and gives the developer finer grained control over the UI.
b) Regarding ORM or no ORM - first, its important to note that you still need to choose a database. ORM is merely a means of abstracting the data access logic away from the developer - but there still needs to be a database to store the data. If you're going with an all Microsoft stack, you'll probably choose SQL Server.
ORM is great for developer productivity - and generally speaking, there's no reason not to choose it for new projects unless you can identify up front that its not going to provide a productivity boost. An example reason why you would choose not to adopt ORM - you need to persist the data in a pre-defined format - or in an already existing database - and the persisted entities are not consistent with how your application is representing them (i.e. over-normalized). In this case, you may want to write your own data access logic, and not rely on an ORM.
Finally, if all you are looking to accomplish is putting a product catalog online, rather than building an application from scratch to do this - you may want to consider utilizing an existing CMS of some sort, or even use Wordpress with some plugins. Would save hours of time and still accomplish your stated goal.
Best of luck!
If you want a really good reference on how to build application using MVC and ORM, then read the following book : Professional ASP.NET Design Patterns
It explains in details as how to build application using MVC. It also covers other interesting topics like dependency injection, repository pattern(very important expecially if you have decided to go for ORM), TDD etc. I hope you will enjoy reading this text.
Related
MVC sets up clear distinction between Model, View and Controller.
For the model, now adays, web frameworks provides ability to map the model directly to database entities (ORM), which, IMHO, end up causing performance issues at runtime due to direct database I/O.
The thing is, if that's really the case, why model ORM is so pupular and every web frameworks want to support it either organically or not.
To a web site has huge amount of traffic, it definitely won't work. But what's the work around? Connect directly to database is definitely not a wise solution here.
What's your question?
Is it a good idea to use direct db access from webpages?
A: No.
Is it a good idea to use ORM's?
A: Debatable : See How can I design a Java web application without an ORM and without embedded SQL
Is it a good idea to use MVC model?
A: Yes - it has nothing to do with "Direct" database access - it's about separating your application logic from your model and your display. (Put simply).
And the rationale for not putting database logic inside webpages has nothing to do with performance - it's about security/maintainability etc etc. Calling a usp from a webpage is likely to be MORE performant than using an ORM, but it's bad because the performance gain is negligible, and the cons are significant.
As to workaround: if you mean how do you hook up a database to a web application...?
The simplest way is to use something like Entity Frameworks or Linq-Sql with your Model - there are plenty of examples of this in tutorials on the web.
A better method IMO, is to have a separate Services layer (which may be WCF based), and have all the database access inside that, with DTO's transferring the data to your Web Application which has it's own ViewModel.
Mvc is not about orm but about separation of display logics and business logics. There is no reason your exposed model needs to be identical to you database model and many reasons to ensure that the exposed model closely matches what is to be displayed.
The other part of the solution to scale well would be to implement caching in the control and be able to distribute load on sevaral instances.
I think #BonyT has given a good answer, (and I've voted for it :) ), I'd just add that:
"web frameworks provide the ability to map the model directly to database entities (ORM), which, IMHO, ends up causing performance issues at runtime due to direct database I/O"
Even if this is true, using an ORM can solve a lot of problems with a model being easy to update and translate back and forth between a database. Solving a performance hit by buying extra web servers or cloud instances is much cheaper than having to buy extra developers or extra hours in development to solve things other people have already written ORMs to do for you.
I am sorry for my question may looking a old repetitive questions but I as I am starting Linq to SQL I want to discuss how many layers (architecture) should I use ?
I am working on web mostly web sites and small to medium scale web applications. I understand dividing application into layers help its maintainanace and enhancement but frankly I want some balance way which give me rapid development and code reuse-ability as well. I cannot spare so much time on unwanted management of layers.
Before I was using 4 layers (business objects, BLL,DAL and user itnerface.) I became confuse on it as different people have described different layers. Please guide me what and how many layers I should use ? Thanks
Don't use the layer architecture. Use the onion architecture.
The most important aspect from architecture perspective is the separation of concerns. Separation of concerns leads to clean code, easy maintenance, extensible, etc. That said, I recommend to base your decisions based on the following criteria:
Try to architect your system in a loosely coupled way. Use messaging instead of RPC as messaging is reliable, scalable, asychronous, loosely coupled, etc. You can either use MSMQ or NServiceBus (for service bus based architecture).
Create layers based on the separation of concerns concept. For e.g. you can go for typical 3 layered architecture which will have just UI layer, business logic layer (business rules+workflow) and data access layer or more granular such as UI layer, services layer (facade), business logic layer, data access layer, etc. Using IoC / Dependency injection will make life easy as none of the layers will have direct dependency. Moreover, it promotes unit testing easy as you inject mocks instead of the real implementations for the unit test. There are so many IoC frameworks available (NInject, Autofac, Castle Windsor, Structure Map, etc...)
Try to use EF instead of Linq to SQL as the later works only with SQL, while the EF works with any database. Moreover, in my opinion, EF is where microsoft is innovating and I would assume that Linq to SQL may be retired one day.
Great question haansi. This is something that I have wrestled with quite often when building small to medium sized sites. Finding that balance of creating a architecture that gives you the greatest flexibility and allows for rapid deployment is what I think we all need to strive for in all of our work.
With that being said, I have found that using the Repository Pattern to be quite helpful with LINQ to SQL projects. I couple that with the Model View Presenter pattern (for WebForms or other projects) and it provides a great foundation for reuse with minimal layers.
My Webform calls a Presenter class, which in turn is responsible for populating the View. To populate that View the Presenter can call N number of Repositories. The Repository is where you encapsulate your DataContext class and your LINQ to SQL calls. These calls return the model classes.
One huge benefit to this regardless of the size of the app is that get great re-use out of your Repository, you get to maximize the use of LINQ and you have used some patterns that other software developers could easily read and support.
Another big benefit is that you now have created a simple architecture that can benefit from using Unit Testing to test from the Presenter back to the Repository without a ton of effort.
Good luck!
I decided to use one layer (DAL + BLL) for small projects and for large applications will use Different layers for DAL & BLL. I will use Linq in DAL and funtiosn will return IQueryable.
In the past I have primarily built all my web applications using an N-tier architecture, implementing the BLL and DAL layers. Recently, I have started doing some RoR development as well as looking into ASP.NET MVC.
I understand the differences between the different architectures(as referenced by some other SO posts), but I can't really think of any reasons why I wouldn't choose an MVC model going forward for a new project.
Is there any reasons/times in your experience when an MVC architecture would not be suitable, or any reasons why you would choose a BLL/DAL architecture instead?
I don't think your options are mutually exclusive. You could perfectly use MVC while using BLL/DAL for your model logic.
You can implement the M part of MVC as you prefer, there is no restriction about that. Using BLL and DAL would be a valid option.
For me? the only reason I'd not use MVC is because the application I'm working on was already started in web forms. I'm not a big proponent of scrap/rewrite, but anything new I do is in MVC.
One of the factors could be the statefulness of your web application. If it's a basic web application that gets everything from the server with a few JavaScript hooks such as client side validations, then the Rails type MVC is really great. I am not familiar with MVC on ASP.NET, but I've heard it's similar to that in Rails.
If the web application is really stateful, then a better approach would be to have a dual MVC layer - one on the client side, and the other for the server. The MVC on the server will mostly concern itself with authentication, authorization, churning out data in standard formats, etc. The client side MVC will concern itself with things such as DOM events, user actions, how they affect the application state, and how/when should data be requested/sent to the server.
MVC is just a way to organize code, just as BLL or DAL would do. MVC in Rails basically hides DAL altogether by using a set of conventions. Usually business logic resides in the models itself. However, if your application demands more complex BLL where object interactions can be intricate, then there's no reason why that BLL can't peacefully co-exist with the M in MVC.
I don't use MVC only on really tiny projects consisting of ~1-2 files and ~10-20 lines of code. And they will hardly evolve into something bigger.
But if they will, it will be time to rearchitect them into a MVC ones.
The only drawback we've had is that MVC pushes you toward a html/javascript interface where rich internet applications become more difficult. For example if you want to present the user with a calendar control, you may need to roll your own since you can't drop one on from the toolbox. That said, MVC is great. When we really need RIA applications we use MVVM and Silverlight.
For certain pages, MVC can be a little overkill:
splash pages
landing pages
marketing pages that are going to be thrown away after one use
one-off's
It's easy to get wrapped up creating a beautiful MVC architecture, when a small page, concisely written, can be OK on these situations.
MVC may also be impractical if you're in time trouble, and you need something out REALLY fast. Like your marketing team is out at a conference, they're having trouble, and needs something to show in their booth this second before they lose their biggest customer.
Life above the service tier suggests you should use the MVC pattern in a way that adheres to the SOFEA principles, and watch out for "Front controller" type frameworks disguising behind the MVC acronym.
(or, you can still use them, but at least read the article, understand the differences and choose wisely).
The simple answer is, no.
MVC is all around a better architecture than your old-school n-tier architecture, for many reasons. It's the standard approach in other UI models (e.g. Swing). The only reason it took so long to make it to web applications was because it took the software community, collectively, a little while to get used to the statelessness of the web and to be able to deal with the views and controllers in a way that made sense.
Personally, I would rate it based on the complexity of the target application. MVC (or more structured approaches in general) lend themselves very well to large scale applications where design consistency and segregation of code is a benefit outweighing the cost of supporting the design.
If its a small site, or very few pages/controls, I would avoid sticking to strict design patterns. But that is just my preference.
As one poster said, you also have to consider the state of any existing applications, and your development team skills / experience.
We have already use the MVC for the Windows application,Now we need to convert that thing in the Web application we don't have any problem in any thing. We are using the Web service and every Business Logic is in the Web service.
So you can use the MVC in the web application.
M-Model(Functions and Procedure which communicate with Business logic)
V-View(Design)
C-Controller(Form Logic)
so that is no connection in the DAL,BLL and in MVC.
you can define your Business logic and use in it any where in the MVC.
That's my point of view MVC is very useful for Re-usability i prefer if your application is big then you must use MVC.
I wouldn't use MVC pattern only in the case when I have an existing desktop application built with MVP and I have to convert it to a web environment. That's because I already have written logic for presenter.
In any other case I would use MVC.
You can refer to following
http://blogs.msdn.com/b/webtopics/archive/2009/09/01/asp-net-mvc-what-is-it-and-should-i-use-it.aspx
and http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080017 refer "Undisputable Facts".
I'm new to MVC structure and feel it's harder to get things done because it's a new way of doing things. Are there anybody who has experience of MVC vs. pages way of doing things. Is the MVC way of doing it the holy graal now or is there still value doing ordinary object-oriented development (or even procedural pages webdev)? Is MVC a fad?
A brief list of pros and cons for MVC
Pros
Testablily
Separation of Concerns - Promotes decoupling between major components
Helps you focus on one task/area at a time
Natural fit for Web and desktop interactions
Fits well with other design patterns, Single Responsibility
Principle etc.
Cons
Can require more code and effort
Can reduce clarity for simple pages (in these cases try to continue using simple pages)
Will take more learning
MVC is much more than a fad. It is a very pragmatic way of separating multiple concerns of a web application into manageable and reusable sections. Granted it does take some getting used to at first, but with some conscious effort at breaking your application up the MVC-style can be very rewarding. Often solutions are more succinct as they only need to concentrate on a single operation or task.
It is not a new idea either. It has been around in one form or another since 1979 (#Sarfraz Ahmed's link) and has been used in various web and desktop platforms.
If you are finding yourself having trouble using an MVC-style implementation then try to break it down into the individual parts or actions that are being used, and their corresponding area, model view or controller. As you probably expected, this will come easier over time.
Good luck
To MVC or not is mostly up to the needs of your project. Sometimes I have simple stuff that doesn't need the Model, but can still benefit from a controller/view arrangement. In those cases I might go with a micro-framework ( for PHP that would be limonade ) or even less. Still the majority of my web projects are MVC applications.
I started making websites around 1996-1997, everything was kind of new and there was no sense to what might be a good or bad idea in the long run. Around 2005 when I left the military and got back into web development it wasn't that enjoyable to fight through rat's nest of organically designed code. So When I was introduced to Ruby on Rails and the concept of MVC, I instantly recognized for myself that this was a game changer.
As MVC is increasingly adopted in more and more web projects, its paving the way for the next generations of developer's lives to be a little easier and more productive by providing common ground across companies and projects. Yes MVC is a little tough to swallow when going from the upfront simplicity of cooperative script to page projects but anything worth doing isn't going to be that easy right?
With all that said, if you get a good grounding in MVC in one language, it can provide a mental common ground for you to learn other languages. As for how long MVC will last as a dominant framework design pattern, the software industry is like a desert, everyday things change and great ideas become eclipsed by better ones (XHR for websockets, embedded objects for native audio/video tags) but I think whatever finally dethrones MVC will be somewhat similar because it doesn't really matter how great an idea is if only a very small portion of people understand it.
If we speak about ASP.NET MVC, the framework page itself has a discussion on this point:
The ASP.NET MVC framework offers the following advantages:
It makes it easier to manage complexity by dividing an application into the model, the view, and the controller.
It does not use view state or server-based forms. This makes the MVC framework ideal for developers who want full control over the behavior of an application.
It uses a Front Controller pattern that processes Web application requests through a single controller. This enables you to design an application that supports a rich routing infrastructure. For more information, see Front Controller on the MSDN Web site.
It provides better support for test-driven development (TDD).
It works well for Web applications that are supported by large teams of developers and Web designers who need a high degree of control over the application behavior.
The Web Forms-based framework offers the following advantages:
It supports an event model that preserves state over HTTP, which benefits line-of-business Web application development. The Web Forms-based application provides dozens of events that are supported in hundreds of server controls.
It uses a Page Controller pattern that adds functionality to individual pages. For more information, see Page Controller on the MSDN Web site.
It uses view state or server-based forms, which can make managing state information easier.
It works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.
In general, it is less complex for application development, because the components (the Page class, controls, and so on) are tightly integrated and usually require less code than the MVC model.
I think this exhaustive list provides answers to all your questions about MVC.
Since you have not mentioned language and if you mean mvc in php then this is also a great
resource for those new to mvc:
http://phpro.org/tutorials/Model-View-Controller-MVC.html
This is from a ASP.NET WinForms -> ASP.NET MVC perspective, however, ASP.NET MVC was the first time I heard of the MVC pattern (noob programmer) and I think if I discovered MVC in another language before ASP.NET MVC, I would've left ASP.NET/C# and went to that framework.
Learning and using MVC has made me a better programmer. I've always felt ASP.NET placed a transparent barrier between myself and the code (HTML or C#).
I've always wanted to break through that barrier, and MVC gives me complete control of everything in my app while emphasizing separation of concerns (something that makes coding infinitely more fun and less of a headache).
For me, MVC was the right choice.
The big advantage of MVC (in general) is that you are far less likely to create monolithic applications. You have a single request-act-response pathway, vs. something like ASP.NET webforms or JSF (although JSF is not as bad as webforms). It's very easy for a small site in webforms to become a big unmanageable tangled mess in webforms, then you have to start whipping out the custom controls and your team is lost. If you understand how the web work, MVC is easy ... although it is then in your hands to manage state.
After struggling with MVC for some time, I have to said that I now much prefer MVP (Model-view-presenter) architecture. Separation of concerns, decoupling and asynchronization are much easier to achieve with MVP than MVC, IMHO, because each MVC implementation doesn't split the concepts the same way, each controller doesn't handle the same things.
I've been reading through a couple of questions on here and various articles on MVC and can see how it can even be applied to GUI event intensive applications like a paint app.
Can anyone cite a situation where MVC might be a bad thing and its use ill-advised?
EDIT: I'm specifically talking about GUI applications here!
I tried MVC in my network kernel driver. The patch was rejected.
I think you're looking at it kind of backwards. The point is not to see where you can apply a pattern like MVC, the point is to learn the patterns and recognize when the problem you are trying to solve can naturally be solved by applying the pattern. So if your problem space can be naturally divided into model, view and controller then it is a good candidate for MVC. If you can't easily see which parts of your design fall into the three categories, it may not be the appropriate pattern.
MVC makes sense for web applications.
In web applications, you process some data (on SA: writing questions, adding comments, changing user info), you have state (logged in user), you don't have many different pages, but a lot of different content to fit into those pages. One Question page vs. a million questions.
For making CMS, for example, MVC is useless. You don't have any models, no controllers, just a pages of text with decorations and menus. The problem is no longer processing data - the problem now is serving that text content properly.
Tho, CMS Admin would build on top of MVC just fine, it's just user part that wouldn't.
For web services, you'd better use REST which, I believe, is a distinct paradigm.
WebDAV application wouldn't benefit greatly from MVC, either.
The caveat on Ruby for Web programming is that Rails is better suited for building Web applications. I’ve seen many projects attempt to create a WebDAV server or a content management system CMS with Rails and fail miserably. While you can do a CMS in Rails, there are much more efficient technologies for the task, such as Drupal and Django. In fact, I’d say if you’re looking at a Java Portal development effort, you should evaluate Drupal and Django for the task instead.
Anything where you want to drop in 3rd party components will make it tough to work in the MVC pattern. A good example of this is a CMS.
Each component you get will have their "own" controller objects and you won't be able to share "control" of model -> ui passing.
I don't necessarily know that MVC is ever really a bad idea for a GUI app. But there are alternatives that are arguably better (and also arguably worse depending on whose opinion you're asking). The most common is MVP. See here for an explanation: Everything You Wanted To Know About MVC and MVP But Were Afraid To Ask.
Although I suppose it might be a bad idea to use MVC if you're using a framework or otherwise interacting with software that wasn't designed with MVC in mind.
In other words, it's a lot like comparing programming languages. There's usually not many tasks that one can say that one is better than the other for. It usually boils down to programmer preference, availability of libraries, and the team's experience.
MVC shouldn't be used in applications where performance is critical. I don't know if this still applys with the increase of computing power but one example is a call center application. If you can save .5 seconds per call entering and updating information those savings add up over time. To get the last bit of performance out of your app you should use a desktop app instead of a web app and have it talk directly to the database.
When is it a bad thing? Where ever there is another code-structure that would better fit your project.
There's countless projects where MVC wouldn't "fit", but I don't see how a list of them would be of any benefit..
If MVC fits, use it, if not, use something else..
MVC and ORM are a joke....they are only appropriate when your app is not a database app, or when you want to keep the app database agnostic. If you're using an RDBMS that supports stored procedures, then that's the only way to go. Stored procs are the preferred approach for experienced application developers. MVC and ORM are only promoted by companies trying to sell products or services related to those technologies (e.g. Microsoft trying to sell VS). Stop wasting your time learning Java and C#, focus instead on what really matters, Javascript and SQL.