locked
MVC or Datasets RRS feed

  • Question

  • Gosh, not sure where to even begin. I’ve been working with .Net since 1.1. The majority of my direction has come from a host of developer books with most of my development experience being smart clients.

     

    Every book I have ever bought has demonstrated basic win form data entry development using Datasets for data management. Some have gotten quite elaborate related to the data access layer to the point of using partial class extensions for overloading fill methods, custom validation of columns, and things like that. For an example of what I am talking about, this highlights the ideas:

     

    http://searchwindevelopment.techtarget.com/tip/0,289483,sid8_gci1278180,00.html#

     

    Things have gone well enough with this. Recently I got to work with another team (a web group) and they employed a basic MVC design, separating things into a UI, Data Access, and Business Logic. What they had was a mess, but I got the point.

     

    I was told by that group, "yea what you're doing is slick, but it isn’t the way the big dog roll" if you will. More so that a lot of employer would balk at my work experince if I didn't follow an MVC design (and kept using datasets).

     

    So I poked around and found out about the Enterprise Library. Sounds great enough but a lot to dig through and I’m not even sure where to start.

     

    Then I started looking at VS2008 (still on 2K5 2.0 for the moment). And sure enough what is there is still Dataset examples that show even more has been added to the Dataset. It looks great (really great). Take a look at this:

     

    http://msdn.microsoft.com/en-us/vbasic/cc138241.aspx

     

    So from what I can see I’m still being told by MS and most of the books to use datasets. But with all that, the slightly larger groups at my employer (who are just now getting off 1.1 and moving to 3.5) are telling me “No No” to datasets for data access and that I should follow their logic (even though it seems a mess).

     

    Can anyone give me some direction?

     

    The biggie I am interest in is Data Access and Business Logic. What is the main stream way to handle this in my apps (web/smart clients/console, etc)? Should I try to go the Enterprise Library route with the Data Access Block or should I continue down the Dataset route?

     

    If I should go the EL route can anyone give me a watered down reference I can look at just showing the basics to get me started?

     

    Thank you in advance for any feedback or direction you can provide.

    Friday, September 12, 2008 8:15 PM

Answers

  • Well, it's not easy to give a rundown on software architecture in two minutes, but I'll see if I can clear up the confusion :-)

    A lot of people throw around terms like MVC/MVP without actually knowing what they really do. However, if you learn nothing else from this experience, then I think it's sufficient to focus on the concept of "Separation of Concerns". What that means is that you don't merge code that handles a lot of different things. Think of it as organizing and compartmentalizing the code into units of responsibility. What you end up with at the end is a number of layers, that when put together, makes the whole app run. Typically, you have UI, business logic, and data access layers. This isn't MVC, by the way, and hopefully that team knows better than to call it that. This is just the typical 3-tier architecture (I'll get to MVC in a minute). Of course, people can and have broken down the layers even further, creating systems commonly referred to now as n-tier. There are a few reasons for doing this. Primarily, it's for maintainability. The biggest work push is in the beginning of the project to implement it, but most of the software's lifetime is actually spent in maintenance mode, and this gets particularly tricky in systems where the users want frequent upgrades in functionality, or the software has to adapt to fluid business needs. When you run into this, you really need code that will be easy to change and still maintain high quality with as few bugs as possible. By separating logic out, you create reusable units, rather than creating the same logic on many UI pages, for example. If you replicate the logic across UI elements, then you end up creating multiple maintenance points. That means that fixing a bug or adding a feature forces you to change code all over the place instead of a single point.

    Also, by having the business logic separated out, you are creating a system of somewhat interchangeable parts. So for example, if a company has an ordering system, and the ordering business logic is separated out, then it can reuse the business logic component in multiple applications - like an in-house ordering desktop app as well as a public website with a shopping cart, and even and XML business-to-business web service. When the business logic needs to be updated, you don't have to replicate the changes or fixes manually in all the applications since all the business logic code lives in a single place. There are many other reasons to do this as well, for example, for scability purposes, but hopefully, this gives you a starting point.

    As far as MVC goes, it's one of the most misused acronyms in computing. It's actually a pattern for handling UIs that dates way back to the mid 80s. In many ways, the original pattern no longer applies to modern software because it was intended for screens before the concept of reusable controls and widgets on forms. However, it did have some interesting principles that evolved and grew up into several more modern patterns like a few flavors of the MVP pattern. Of course, a lot of people still use the acronym, and MS even put out a new ASP.NET project type with the name MVC.

    Even though the original MVC pattern no longer really applies, a few of its core principles are still very valid and seen in several new patterns. The point is that you separate the UI into sub-components, which helps with the maintainability and quality of the code. The "M" part of the acronym stands for Model, which in a way is an extension of the business logic layer. In pure Object-Oriented-Programming terms, it means that you model your business data into entity objects, where they are stored in a manner that abstractly represents the business concepts (instead of flat tables of data, or data strewn out through a ton of variables). You end up with Customer objects, Order objects, ect., which to a large degree might look and feel a lot like the typed datasets you are already using. The "V" stands for View, which is basically the forms/controls/widgets that make up your screen. Under this pattern, the view should have no code that handles business scenarios or logic, it just knows how to display itself. It also uses the Model objects to populate the forms, but the model objects "own" the data itself. The model objects are also "observable", meaning that if you change the data, they notify (by events perhaps) you that something was changed. The View uses these notifications to update itself. It's a bit like binding, but a little more involved in some respects. Lastly, the "C" stands for controller. It is a piece of code (class) that coordinates the interaction between the View widgets and the Model data objects. The type and extent of the coordination depends heavily on the flavor of MVC or MVP pattern being used. But classically, the view widgets don't handle user input, like button clicks.. they hand off the user events to the Controller, which in turn invokes business logic and updates the Model.

    Having said all that, it isn't necessarily clear that this kind of architecture is good for all projects. There are tons of line-of-business applications (smaller scale every-day business helpers if you will) that use datasets and work just fine. Like all things in software, it's about tradeoffs. Using techniques like n-Tier and MVC/MVP is great, but comes at a cost (of complexity and work) as well. You really have to balance what approach is most usefull in the grander scheme of things.

    Anyway, it's not easy to cover so much material in a single post, but i hope this is a good start for some understanding.
    -Rob Teixeira
    Friday, September 12, 2008 9:14 PM

All replies

  • Well, it's not easy to give a rundown on software architecture in two minutes, but I'll see if I can clear up the confusion :-)

    A lot of people throw around terms like MVC/MVP without actually knowing what they really do. However, if you learn nothing else from this experience, then I think it's sufficient to focus on the concept of "Separation of Concerns". What that means is that you don't merge code that handles a lot of different things. Think of it as organizing and compartmentalizing the code into units of responsibility. What you end up with at the end is a number of layers, that when put together, makes the whole app run. Typically, you have UI, business logic, and data access layers. This isn't MVC, by the way, and hopefully that team knows better than to call it that. This is just the typical 3-tier architecture (I'll get to MVC in a minute). Of course, people can and have broken down the layers even further, creating systems commonly referred to now as n-tier. There are a few reasons for doing this. Primarily, it's for maintainability. The biggest work push is in the beginning of the project to implement it, but most of the software's lifetime is actually spent in maintenance mode, and this gets particularly tricky in systems where the users want frequent upgrades in functionality, or the software has to adapt to fluid business needs. When you run into this, you really need code that will be easy to change and still maintain high quality with as few bugs as possible. By separating logic out, you create reusable units, rather than creating the same logic on many UI pages, for example. If you replicate the logic across UI elements, then you end up creating multiple maintenance points. That means that fixing a bug or adding a feature forces you to change code all over the place instead of a single point.

    Also, by having the business logic separated out, you are creating a system of somewhat interchangeable parts. So for example, if a company has an ordering system, and the ordering business logic is separated out, then it can reuse the business logic component in multiple applications - like an in-house ordering desktop app as well as a public website with a shopping cart, and even and XML business-to-business web service. When the business logic needs to be updated, you don't have to replicate the changes or fixes manually in all the applications since all the business logic code lives in a single place. There are many other reasons to do this as well, for example, for scability purposes, but hopefully, this gives you a starting point.

    As far as MVC goes, it's one of the most misused acronyms in computing. It's actually a pattern for handling UIs that dates way back to the mid 80s. In many ways, the original pattern no longer applies to modern software because it was intended for screens before the concept of reusable controls and widgets on forms. However, it did have some interesting principles that evolved and grew up into several more modern patterns like a few flavors of the MVP pattern. Of course, a lot of people still use the acronym, and MS even put out a new ASP.NET project type with the name MVC.

    Even though the original MVC pattern no longer really applies, a few of its core principles are still very valid and seen in several new patterns. The point is that you separate the UI into sub-components, which helps with the maintainability and quality of the code. The "M" part of the acronym stands for Model, which in a way is an extension of the business logic layer. In pure Object-Oriented-Programming terms, it means that you model your business data into entity objects, where they are stored in a manner that abstractly represents the business concepts (instead of flat tables of data, or data strewn out through a ton of variables). You end up with Customer objects, Order objects, ect., which to a large degree might look and feel a lot like the typed datasets you are already using. The "V" stands for View, which is basically the forms/controls/widgets that make up your screen. Under this pattern, the view should have no code that handles business scenarios or logic, it just knows how to display itself. It also uses the Model objects to populate the forms, but the model objects "own" the data itself. The model objects are also "observable", meaning that if you change the data, they notify (by events perhaps) you that something was changed. The View uses these notifications to update itself. It's a bit like binding, but a little more involved in some respects. Lastly, the "C" stands for controller. It is a piece of code (class) that coordinates the interaction between the View widgets and the Model data objects. The type and extent of the coordination depends heavily on the flavor of MVC or MVP pattern being used. But classically, the view widgets don't handle user input, like button clicks.. they hand off the user events to the Controller, which in turn invokes business logic and updates the Model.

    Having said all that, it isn't necessarily clear that this kind of architecture is good for all projects. There are tons of line-of-business applications (smaller scale every-day business helpers if you will) that use datasets and work just fine. Like all things in software, it's about tradeoffs. Using techniques like n-Tier and MVC/MVP is great, but comes at a cost (of complexity and work) as well. You really have to balance what approach is most usefull in the grander scheme of things.

    Anyway, it's not easy to cover so much material in a single post, but i hope this is a good start for some understanding.
    -Rob Teixeira
    Friday, September 12, 2008 9:14 PM
  • That was the kind of info I was looking for. Thank you so much for the feedback. I greatly appreciate it.
    Monday, September 15, 2008 4:12 PM