Database First Design vs. Class First Design
No matter what the project, some developers are database first kinds of developers. They immediately start building tables, stored procedures and views before writing a single line of code. Once this is accomplished, they then start to pick apart the other layers of the application and determine how the application will pass data between the layers. This database first notion more times than not results in more Table Data Gateway and Table Module Patterns and the use of the DataSet as a container to pass data between the layers of the application. Certainly there is no rule that says you can't use custom objects when starting with a Database, it has just been my experience that this tends to be the norm.
On the otherhand, class first types of developers tend to focus on the problem domain first, and the result are custom objects. Once all the custom objects are built, you usually have some type of object repository (aka Domain-Driven Design) that hides / handles the persistence of the objects. Here you get into more Data Mapper Patterns that bridge the object world to the relational database world, etc.
Full Article :
Objects vs. DataSets - Is it Really About the Technical Aspects?
I have been meaning to talk about Objects vs. DataSets ever since Ambrose Little's session at the Tampa Code Camp as well as my reading of Dino Esposito's Cutting Edge Article, DataSets vs. Collections, in the August 2005 Edition of MSDN Magazine.Both Ambrose's session and the Cutting Edge article were informative, but they only talk about Objects vs. DataSets from a purely technical aspect, which I think is only half the picture. Also, much of the technical cons discussed about Objects were about the time and energy needed to create them, which is a fairly weak argument given the use of 1) Code Generation Tools, and 2) O/R Mappers to help you with much of the plumbing and bare bone classes.
In this post I want to change the focus from technical aspects to more project, project methodology, and developer preference aspects. In general, I want to focus on the following:
- Domain-Driven Design vs. Database-Driven Design
- Database First Design vs. Class First Design
- One-Time Applications vs. Evolutionary Applications
- Novice Developers vs. Experienced Developers
Disclaimer: I am sure there are other things we could talk about, but these are the topics that initially come to mind. The items being mentioned are certainly just my opinion and aren't written in stone. I also don't claim to be an expert on these ideas. I just want to look at these choices from a different view.
Domain-Driven Design vs. Database-Driven Design
Projects come in all shapes and sizes. Some are a mere shell around a database with few business rules (Database-Driven Design) while others are more complex in nature with a sophisticated problem domain (Domain-Driven Design).
If your new project centers around a database and is mainly about pulling data to and from a database and reporting on that data, a DataSet is a very attractive solution. The DataSet has so much built-in functionality for these types of projects that you would be silly to not consider them. New feature in ASP.NET 2.0, such as the DataSource Controls, also give you a lot more functionality when using DataSets for these types of applications. Using custom objects for database-driven projects doesn't really require much more effort if using a good Code Generation Tool, but if you are hand-coding this functionality, you are probably not getting much bang for your buck as you will be handcoding a lot of functionality that you get for free in the DataSet.
If your project has a problem domain rich with business rules, behaviors, a complex class hierarchy, and persistence is very much NOT the focus, custom objects will better give you the flexibility and functionality you desire. Collaboration between objects and the assignment of responsibilities will be foremost in your mind and the actual repository for the object data will be the least of your concerns. DataSets don't fair as well in these types of projects given the limited ability to add business rules and responsibilities as well as express your problem domain to its richest extent.
Database First Design vs. Class First Design
No matter what the project, some developers are database first kinds of developers. They immediately start building tables, stored procedures and views before writing a single line of code. Once this is accomplished, they then start to pick apart the other layers of the application and determine how the application will pass data between the layers. This database first notion more times than not results in more Table Data Gateway and Table Module Patterns and the use of the DataSet as a container to pass data between the layers of the application. Certainly there is no rule that says you can't use custom objects when starting with a Database, it has just been my experience that this tends to be the norm.
On the otherhand, class first types of developers tend to focus on the problem domain first, and the result are custom objects. Once all the custom objects are built, you usually have some type of object repository (aka Domain-Driven Design) that hides / handles the persistence of the objects. Here you get into more Data Mapper Patterns that bridge the object world to the relational database world, etc.
One-Time Applications vs. Evolutionary Applications
Some applications are simple and are built to solve a known problem. There is very little notion of adding functionality or coming out with new versions. The ability to maintain and extend fuctionality is of very little concern. You just need to get the application out and solve the immediate and current need. These applications tend to be more drag-n-drop, Rapid Application Development applications that once finished will “never” be touched again. Developers use every feature built into .NET and the Visual Studio IDE to complete the project in the least expensive and fastest way possible. These applications seem to be a natural fit for the DataSet given that it is built into .NET and a first class citizen of the Visual Studio IDE.
Other applications are evolutionary. Although the idea is to get out a version 1.0 as soon as possible, the intent is that the application itself will grow with the needs of the customers and be very flexible and extensible to handle new, different, and better technologies. The business model is very much based on a subscription model as well as grabbing marketshare from different platforms, operating systems, databases, programming languages, etc. The layers of these applications are based very much on abstraction, loose-coupling, providers, put your overused buzzword here :) The application needs to be highly maintainable and extensible, which often comes from using custom objects.
Novice Developers vs. Experienced Developers
New developers to .NET will embrace the DataSet for the reasons mentioned above - it is built into .NET and a first class citizen in the Visual Studio IDE. They can leverage the drag-n-drop functionality as well as the rich components in the IDE to limit the amount of code they need to write. This is not only smart, but the marketing push done by Microsoft to sell ASP.NET 2.0. Most of their applications will be database-driven and database reporting in nature as well, so the DataSet seems to be a natural fit. The focus will be on less code and more drag-n-drop and leveraging built-in functionality.
More experienced developers will be hired as well as seek those projects that are more challenging - Enterpise Applications if you will. Drag-n-drop will not always meet their needs as the problem at hand is usually not so cut-and-dry. The Enterprise Applications will have a more complex problem domain that realistically only custom objects will satisfy for reasons mentioned above. However, we are talking about experienced developers here seeking a challenge, so they wouldn't be satisfied by using a DataSet or drag-n-drop anyway. They not only want to use those aspects of .NET that are a bit more obscure and challenging, they won't be satisfied if they don't use it. This is hardcore development at its best, at least as hardcore as you can get from a managed language :)
Conclusion
I find that that the most interesting reasons for choosing Objects vs. DataSets are less technical, but more about the project, the developer's methodology, and the developer's preference. The technical reasons for choosing one over the other are pretty weak and can be resolved pretty easily. Many of the reasons for choosing one over the other is based on the project, developer preference, the development methodology, and the experience of the developer. Ideally, one would want to leverage them both to their maximum extent and not look at one as better than the other, but that they both serve a purpose depending on the context of the situation.
Have fun with this stuff and let the project dictate the best possible solutions and tools. If you notice your preferences and experience sway the solutions and tools in a particular way that may not be the most appropriate for the problem, welcome to the human race. Build those skills that make you
No comments:
Post a Comment