Hi, first of all I just wanna to tell u that im not trying to criticize Microsoft.( I will never do) I just wanna clarify some things off the shelf. So I just thought to have some discussion with some professionals I know. Mahasen is a great Software Architecture I know.. So this discussion will be really helpful for other developers. You can download the Patterns & Practices design guidelines in PDF format from the Microsoft Patterns & Practices site (http://msdn.microsoft.com/practices/Topics/default.aspx) I recently read a complete guide for the Application Architecture for .Net: Designing Applications and Services. It’s really a good one. But there are some few things which I couldn’t agreed with them. Normally I prefer to represent data as objects or collections (to do a proper OOP I guess???) I hate to use typed Dataset, (I completely gave up studying Football 24/7 sample app bcoz of the typed DataSet) I mean it’s really messy. I always wanted to think a problem as it in the real world & map it to the programming world. This makes my task really easier. Here is what Microsoft says about passing objects through layers.(from the above P&P guide)
“It is recommended that you avoid designs requiring you to transfer data in a custom object-oriented format, because doing so requires custom serialization implementation and can create a performance overhead. it will be simpler just to work with the business data in a DataSet.”
So I just wanna know what u guys think about this...
Glad to hear that your idea of this discussion is in harmony with mine. First of all I have to make a small correction though – I’m not an architect – I’m software engineer – at least 4~5 years of experience behind from an architect.
I’m also delighted about the first topic you want to discus about as it is one of my favourites. Basic OOD and the role of DataSets in it.
First of all let me state my idea of OOD: “Modelling real world problem scenarios (entities and concepts) in an abstraction level, which enables to manage the complexity of the problem, in order to solve the real world problem”
In this view a DataSet is a model of the data source with functionality required to cache, serialize, update etc.
The paragraph in the article you mention is “The data format you choose to use depends on how you want to work with the data. It is recommended that you avoid designs requiring you to transfer data in a custom object-oriented format, because doing so requires custom serialization implementation and can create a performance overhead. Generally, you should use a more data-centric format, such as a DataSet, to pass the data from the data access logic components to the business layers, and then use it to hydrate a custom business entity if you want to work with the data in an object-oriented fashion. In many cases, though, it will be simpler just to work with the business data in a DataSet.”
Note that what it advises is to use datasets to pass data between the data access logic components and business layers. You should not misinterpret it as between all layers. Before discussing the suitability, let’s identify what’s passed in-between these components.
The responsibility of a data access layer is to act as a façade to the business logic layer. It encapsulates all the functionality to work with data sources. So the datasets are closer to the data access layer in the sense they are meant to model data source.
The business components are the ones that model the actual problem scenario. They encapsulate the business concepts and logical implementations of them. This means custom objects, which are actually models of business entities, are closer to the business logic components.
What pass in-between these two layers are requests for data from data source and the responses to those requests, updates to data source and the state of the data source.
We could use objects that are closer to business components and let the transformation take place in the data access layer or we could use objects which are closer to the data access layer and let the transformation happen in the business layer.
So far I think I have made it clear that use of datasets does not violate object oriented concepts. So now let me discuss why they say datasets are more suitable.
Often in enterprise applications, business logic components and data access components are separated physically. Ability to separate layers from processes / physical layers is one of the advantages in a good design. There are certain concerns and challenges which the design of objects that are used to transfer in-between these boundaries should address such as performance and serialization issues.
If we are to use our own custom object we should make the extra effort of designing and developing our objects so that they are suitable for these scenarios. But as you know reusing is one of the main concepts behind OOD & OOP. So given the option between a custom object which we need to develop above additional features and the datasets which already has a proven implementation advising to use datasets makes lot of sense.
Let’s not forget that there could be exceptions. In a simpler application which would never grow into multiple physical tiers this could be an overhead. As I mentioned our model should adequately manage the complexity of the problem. It shouldn’t complicate things more than they are nor should it take things too simple.
Hi, Ludmal, I wonder how u gonna say Football 24/7's architecture is bad and a mess. I also studied Football 24/7's architecture and learned lot of things including using typed datasets in a distributed architecture. They had implemented those applications in a really nice architectural manner.
Only problem with that was its business layer is coupled with the database little more. But I don't think that’s a big issue to give that up.
But I don’t like to use datasets or typed datasets in web applications since its overhead is high.
yo madhawa, i didnt say football 24/7 got a bad architecture,i said i gave up studying becoz it used the typed datasets in the UI, I know its good DVD with some really good help feautures.. but what i dont like to see is messing with the UI layer. As u mentiond I personally dont like to use typed datasets in the UI layer nor the business layer. But as mahasen explaind we could use dataset/xml etc... from the datalayer to business layer. But if u read Application Architecture for .Net: Designing Applications and Sevices you'll get to know why we shouldnt use Custom objects to represents data. stick to this discussion & bring ur ideas..
I want to stress that I do not wish to tolerate imprudent comments from people who aren’t matured enough to identify civilized from uncivilized.
Come on now fellows; don’t make this a forum to settle your personal disputes. Lets have a civilized conversation about Microsoft® Patterns and Practices expressing our own views with an open mind with the intension of improving our own knowledge while allowing who ever reads this to benefit from it as well.
And if you guys really want to discuss about this football 24/7 DVD share it with me as I don’t have a clue for what is in it.
Further to my previous comments, I’d like to add following in favor of Microsoft’s comment “...In many cases, though, it will be simpler just to work with the business data in a DataSet”.
Read it carefully again... emphasize on the word simpler. Does it say better? No. it says simpler. Why simple? you may ask. Because KISS (Keep It Simple, Stupid) and SMILE (Simple Makes It Lot Easier) are basic principals behind application design.
Let’s keep in mind that among many advantages like reusability manageability and extendibility object orientation also has few disadvantages like high resource requirements. So if you add any thing unnecessary to your design it is these disadvantages that you elevate.
A common mistake that most novice architects make is making things too complex than needed. Managing complexity is an art that talented and experienced architects excel in. in OOD our goal should be to model the existing problem so that we could solve the existing problem. Not to create new problems so that we could enjoy solving them. Not to apply neat new patterns we just learned in to a problem that doesn’t exists. We model real world entities and concepts, any thing in addition to that should only be added to facilitate adoption to the infrastructure.
An architect is not a person who just designs application; he makes crucial decisions on things like potential growth of the application, areas in which the requirements could change, best equations for resources, time and features (some times with all three values are given as constants! – time could be expanded and resources could be shadowed) etc. So his / her design trades with all those aspects as well.
For example if our application is a simple online kiosk, which displays search results in a grid, which would reside in our only server in which we have both IIS and SQL Server. Why should we make biding data to that grid any complicated than filling a dataset using a DataAdapter and setting the data source in the code behind itself? I believe any more work would just be an overhead.
If we have a well normalized data base design, entities in the database would most probably resemble our business entities. When a typed data set is created to model that, with all that neat relationships and functionality, all which is left for us is to weave the concepts in to solve our problem. So why should we waste time and money developing another layer to represent the same thing unless it is enforced by complex scenarios and infrastructure requirements?
Sure; you may say that’s the approach of an elementary level developer. I say if there’s an elementary level problem, it should be solved with an elementary level solution. Should we let our arrogance waste precious development time? Of cause an elementary level application today has the potential of growing in to an enterprise application. It is the responsibility of an architect to foresee that potential and tailor an adequate design within the triangle of time, resources and features.
Both of you have mentioned that you don’t like to use datasets. Any one can have their personal preferences to technology. But I do use datasets in all three layers depending on the requirement. I find it really simple to work with them and they enable me to finish small scale applications within hours which other wise could have taken days if not weeks. There are instances where I don’t use them at all but it’s not based on personal preference but based on the requirement and the nature of the application.
Oops I forgot to mention about the Typed Datasets in the above comment. (DataSet, XML, etc… ‘etc’ couldn’t do it). What I was trying to explain is from the Mahasen’s post (his first comment) the conclusion I got is to pass DataSet, TypedDataSet, XML etc.. to the business layer & pass the Business Entities, Custom Collections, etc.. etc to the UI Layer. Check the simple diagram.(http://ludmal.blogspot.com ) “There are instances where I don’t use them at all but it’s not based on personal preference but based on the requirement and the nature of the application.” I totally agreed with you. KISS (its nice saying) is the best approach while we architecture our software’s. Always the solution has to be simple. I just read a nice article about the DataSet vs collections (thought it would be helpful to this thread) http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx and found a nice comparison table about DataSet, Typed DataSet, & Custom business Entities.. you can find it here.http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx?fig=true#fig3 .
There are certainly performance differences between DataSets and custom collections. Isn’t it easier to solve a problem in a real OOD manner? Anyhow it’s totally not about the personal preferences; it’s just a matter of complexity of the application & the problem we’re trying to solve. I have seen many posts & arguments about the Dataset vs custom Collections. But the best thing is to know the pros & cons, and to apply them to the relevant situation. With .Net 2.0, features like Generics & IBindingList will give the developer opportunity to generate collections more quickly & effectively.
I would like other developers to share their comments with us so that we, as a small .net community can go ahead & find better .Net solutions for more complex problems.
While I was reading about the DataSet last night I found some good pros of datasets. (http://objectsharp.com). I summarized it & posting here it might give you some idea about the datasets. • They are very bindable. This is less of an issue for Web forms which don't support 2 way databinding. But for Win forms, datasets are a no brainer. Before you go and say that custom classes are just as bindable and could be, go try an example of implementing IListSource, IList, IBindingList and IEditableObject. Yes you can make your own custom class just as bindable if you want to work at it. • Easy persistence. This is a huge one. Firstly, the DataAdapter is almost as important as the DataSet itself. You have full control over the Select, Insert, Update and Delete sql and can use procs if you like. There are flavours for each database. There is a mappings collection that can isolate you from changes in names in your database. But that's not all that is required for persistence. What about optimistic concurrency? The DataSet takes care of remembering the original values of columns so you can use that information in your where clause to look for the record in the same state as when you retrieved it. But wait, there's more. Keeping track of the Row State so you know whether you have to issue deletes, inserts, or updates against that data. These are all things that you'd likely have to do in your own custom class. • They are sortable. The DataView makes sorting DataTables very easy. • They are filterable. DataView to the rescue here as well. In addition to filtering on column value conditions - you can also filter on row states. • Strongly Typed Datasets defined by XSD's. Your own custom classes would probably be strongly typed too...but would they be code generated out of an XSD file? I've seen some strongly typed collection generators that use an XML file but that's not really the right type of document to define schema with. • Excellent XML integration. DataSets provide built in XML Serialization with the ReadXml and WriteXml methods. Not surprising, the XML conforms to the schema defined by the XSD file (if we are talking about a strongly typed dataset). You can also stipulate whether columns should be attributes or elements and whether related tables should be nested or not. This all becomes really nice when you start integrating with 3rd party (or 1st party) tools such as BizTalk or InfoPath. And finally, you can of course return a DataSet from a Web Service and the data is serialized with XML automatically. • Computed Columns You can add your own columns to a DataTable that are computed based on other values. This can even be a lookup on another DataTable or an aggregate of a child table. • Relations Speaking of child tables, yes, you can have complex DataSets with multiple tables in a master detail hierarchy. This is pretty helpful in a number of ways. Both programmatically and visually through binding, you can navigate the relationship from a single record in master table to a collection of child rows related to that parent. You can also enforce the the referential integrity between the two without having to run to the database. You can also insert rows into the child based on the context of the parent record so that the primary key is migrated down into the foreign key columns of the child automatically. • Data Validation DataSets help with this although it's not typically thought of as an important feature. It is though. Simple validations can be done by the DataSet itself. Some simple checks include: Data Type, Not Null, Max Length, Referential Integrity, Uniqueness. The DataSet also provides an event model for column changing and row changing (adding & deleting) so you can trap these events and prevent data from getting into the DataSet programmatically. Finally with the SetRowError and SetColumnError you can mark elements in the DataSet with an error condition that is can be queried or shown through binding with the ErrorProvider. You can do this to your own custom entities with implementation of the IDataErrorInfo interface. • AutoIncrementing values Useful for columns mapped to identity columns or otherwise sequential values.
First of all I’d start by commenting on some of your statements in yesterdays post. (No offence meant – pardon if my words are too harsh) “Oops I forgot to mention about the Typed Datasets in the above comment. (DataSet, XML, etc… ‘etc’ couldn’t do it). What I was trying to explain is from the Mahasen’s post (his first comment) the conclusion I got is to pass DataSet, TypedDataSet, XML etc...”
TypedDataSets are inherited from DataSet class, so in our context by the laws of polymorphism you do not have to mention TypedDataSets again. When you say DataSets you are already referring to TypedDataSets as well. The article you referred mentions it separately because the specializations of TypedDataSets are discussed.
Talking about that article, it seems that it has missed out the sophisticated transaction handling capabilities of datasets. May be because he thought it’s not relevant for data transferring but I still believe it should have been discussed in favor of DataSets. It also does not mention patterns and practice recommendation of hydrating a custom entity using the dataset, which preserves the true object orientation at the business components level. There are few more contradictions in that article but since it’s not our primary goal to criticize it I’ll refrain from doing so.
On the other hand you could have done a better refinement to your previous post by describing the process of passing XML across tiers briefly. Especially in-between business logic components and data access layer. Hope you weren’t referring to objects that hold xml as it would be another case of you dual referencing the same scenario. And I also rule out webservices on this regards as it is more a business component to business component or business component to UI layer transferring. They use xml as their transferring media (Ways of passing raw xml is another interesting topic in its own which we should discuss later in detail)
You comment me saying selecting of technology should be done based on requirements not on personal preferences and say “...I totally agreed with you.” And later in the post you say “Anyhow it’s totally not about the personal preferences; it’s just a matter of complexity of the application & the problem we’re trying to solve” putting forward another question which I may answer in due course. But in your earlier comment you say “...I personally dont like to use typed datasets in the UI layer nor the business layer” I find these two statements to be in contradiction to each other. Is it that you changed your personal views or I misunderstood you once? (Hope not twice)
Towards the end of the post you state “But the best thing is to know the pros & cons, and to apply them to the relevant situation.” Stating about the use of custom objects and datasets; Which, I feel is a shift away from the stance you held when you started this thread. It could very well be that I misunderstood you. I’d like others to comment on this.
In your latest post you go on to complement DataSets and TypedDataSets almost as if you are writing an article on them. I do not want to believe you started this conversation without knowing these things. Had you not known these facts till you read this specific article, I think you had no ethical right to say “...I personally dont like to use typed datasets in the UI layer nor the business layer”. What you should have said is some thing like – “I do not know of the advantages of using datasets neither in UI layer nor the business layer”. More over I find you shifting from our topic of best practices to talk about DataSets. If you do agree with me on my posts you should state so and continue on the topic in hand. If you wish to talk about datasets we shall talk in a new thread. I think for comments like you previous, your own blog is a much suited forum. We aren’t co composing an article here. This is a technical conversation to logically reciprocate concepts in Microsoft patterns and practices. Others please comment on this.
Deviating from those comments of yours, which I find to be contradictory, I’d like to answer your question, “Isn’t it easier to solve a problem in a real OOD manner?”, I would like you to define what you mean by “real OOD manner” to give an detailed answer. But for now based on my definition of object oriented design the answer is not always. I’d explain with samples when you provide your definition.
Yes. Certainly Generics but more or less the consumer-provider model involving the IBindingList interface would make the life of developers easier. But it has no effect on the role of DataSets and their use in applications designed for framework 2.
I do agree with your last invitation and do urge other developers to share their view.
I’d also like to escalate that I feel this conversation is deviating from our original topic, which you started by raising a concern about Microsoft’s architectural suggestion and I replying defending that with logical facts. But your last post does not seem to put forward a new issue nor does it challenge the logics in my comments.
This is some thing I do not wish to let happen. We should be reciprocating technical concerns rather than stating glamorous slogans without any logical facts to back them up.
So as a measure to move this conversation forward in a productive way, I request you to explain your view of object oriented application design in detail.
If we both agree on an informal definition we could move forward in to discussing Microsoft guidelines for application architecture with “Application Architecture for .Net: Designing Applications and Services” article as a general guide line. We could start each new issue in a new post so things don’t get to messy.
I also appreciate if you write a descriptive summary on the contents together with the links to the articles you refer but not a downscaled version of the entire article. So readers wouldn’t have to read an entire article to follow this thread.
I eagerly invite other interested bloggers to participate in this conversation in a semi-professional manner (I discourage complete informality to safeguard the dignity of the subjects that we talk about and opt out complete professionalism so that our views could be clearer.)
(No offence meant – pardon if my words are too harsh) I want you to know that when I mentioned “DataSet, XML, etc… couldn’t do it” (PLEASE note the “couldn’t do it” part), I received lots of personal comments saying that why you don’t want to use typed datasets - that’s why I said “‘etc’ couldn’t do it”. When we are talking about datasets I believe that we have to declare them separately i.e. if I say to a developer to use Datasets he will be wondering what to use. Still I don’t see it as a major issue by declaring them separately.
About the articles I mentioned, I just wanted to know about the differences between DataSet/Custom Entities. It’s just “see also” stuff. If somebody wants more info, they should read that. I didn’t want to extend my post & to make it dreary for the readers.
I think what we’re having here is a discussion & not a argument coz since we’re talking about the same subject in harmony and as I told you before I just want to discuss about the Microsoft Patterns & Practices - not to criticize it.
“...I personally don’t like to use typed datasets in the UI layer nor the business layer” - I know what I said. but while we’re discussing, I came to a conclusion that it’s totally not about the personal preferences; it’s just a matter of complexity of the application & the problem we’re trying to solve. We’ll get conclusions while we’re discussing. That is why we’re discussing. Isn’t it?
I do agree with you and I apologize for it, that I was slightly out of the track on discussing Microsoft Patterns & Practices. I really don’t want to pinpoint things and defend myself. It doesn’t make sense to all of us. No one will get benefits from it. I’m back on track I guess with Microsoft P&P. And I also wanna keep posts small & simple (KISS). Lengthy posts are really hard to follow & it makes dreary for the readers.
What is real OOD? The fact is that true object oriented design is to map the programming world to the real world while trying to model the solution as it was in the real world. In object oriented design complexity is managed using abstraction. If we’re trying return a Customer Dataset instead of a CustomerCollection will it be a true OOD?
What Microsoft saying is “Custom business entity components are not a mandatory part of all applications? Many solutions (especially ASP.NET-based applications and business components) do not use custom representations of business entities, but instead use DataSets or XML documents because they provide all the required information and the development model is more task and document- based as opposed to object-oriented.”
I need comments about this & the same time we’re still inviting other developers out there to share they’re ideas with us. It will be beneficial to all of us.
I do not quite understand your first paragraph. But as you state it’s insignificant – I guess its fine. Your second paragraph seems to be referring to me saying about briefing articles. What you say is fair enough but what I was referring to is you making entire posts on a single article.
Yes it is a discussion, not an argument nor a public bulletin board. But it didn’t seem that way in previous posts of yours. That’s why I had to make my last post. The conversation wasn’t leading any where and it was completely out of track.
Yes. We discuss things to arrive at a conclusion. But when you agree to some thing you should state I agree without going on repeating the same stuff as the other in your own words. Other wise how come that be considered as the conclusion?
I’m glad that we are back on track and hope to stay that way.
I would like to refine your definition as “An object oriented software design is an abstract model of entities and concepts of the problem (not necessarily of real world) and adaptive components to the target domain in which the system would exist” with your agreement on this definition as a condition, the answer to your question is, It’s not a customer dataset that’s going to represent a customer collection object but a customer datatable object. (dataset contains a collection of tables and relationships representing many entities). In a normalized database (which should be if well designed) a single row of a table (in our scenario customer table) represents a problem domain entity. There by a table represents a collection of entities. (Dinesh, who I believe is following this thread, should be able to shred better light on this argument) and the relation ships of that table with other tables in the database represents the problem domain relationships. A datatable is a abstraction of a database table. There for in our scenario it certainly does represents a collection of customers and could be used in place of a customercollection. Also a datarow in that table represents a customer while the relationships account for aggregations and compositions. All that is left to do in a typed dataset is to implement required methods and events to adopt them directly to business domain.
“Custom business entity components are not a mandatory part of all applications. Many solutions (especially ASP.NET-based applications and business components) do not use custom representations of business entities, but instead use DataSets or XML documents because they provide all the required information and the development model is more task- and document- based as opposed to object-oriented.”
This is exactly why I answered not always for your question in my last post. Object orientation should be used to address complex solutions or solutions that has high probability to become complex. For straight forward applications that involve little business logic but could involve a great deal of data representations and repository, object orientation could be a great over head. For an application of that sort what is required is data transformation in between data repository and UI with minimum intervene while transferring. Majority of the transformations could take place at the data access level itself. And in certain cases ease of development also count. For example binding a grid to a dataset is the easiest way to do it for an application that allows a user to view and edit related hierarchical data. As you agreed with me (for what I understood) “it’s just a matter of complexity of the application & the problem we’re trying to solve” the technology used should be selected based on that. That applies to object orientation as well.
If you agree with me on this, please state so that we could continue to another topic. If not we shall discus things in more detail so with input of us both we could arrive at a conclusion.
I’m joining hands with you to invite others to join in and contribute with their valuable input.
Yep mahaesn, I agreed. But it would be better discussion if some other developers also share their view on that topic. So what are we going to discuss….Any ideas…
I’m planning not to do conversations unless some one requests me to. But if you start up some thing in your blog, I will contribute to it with pleasure.
Hi, first of all I just wanna to tell u that im not trying to criticize Microsoft.( I will never do) I just wanna clarify some things off the shelf. So I just thought to have some discussion with some professionals I know. Mahasen is a great Software Architecture I know..
ReplyDeleteSo this discussion will be really helpful for other developers. You can download the Patterns & Practices design guidelines in PDF format from the Microsoft Patterns & Practices site (http://msdn.microsoft.com/practices/Topics/default.aspx) I recently read a complete guide for the Application Architecture for .Net: Designing Applications and Services. It’s really a good one. But there are some few things which I couldn’t agreed with them. Normally I prefer to represent data as objects or collections (to do a proper OOP I guess???) I hate to use typed Dataset, (I completely gave up studying Football 24/7 sample app bcoz of the typed DataSet) I mean it’s really messy. I always wanted to think a problem as it in the real world & map it to the programming world. This makes my task really easier. Here is what Microsoft says about passing objects through layers.(from the above P&P guide)
“It is recommended that you avoid designs requiring you to transfer data in
a custom object-oriented format, because doing so requires custom serialization
implementation and can create a performance overhead. it will be simpler just to work with the business data in a DataSet.”
So I just wanna know what u guys think about this...
Glad to hear that your idea of this discussion is in harmony with mine. First of all I have to make a small correction though – I’m not an architect – I’m software engineer – at least 4~5 years of experience behind from an architect.
ReplyDeleteI’m also delighted about the first topic you want to discus about as it is one of my favourites. Basic OOD and the role of DataSets in it.
First of all let me state my idea of OOD: “Modelling real world problem scenarios (entities and concepts) in an abstraction level, which enables to manage the complexity of the problem, in order to solve the real world problem”
In this view a DataSet is a model of the data source with functionality required to cache, serialize, update etc.
The paragraph in the article you mention is “The data format you choose to use depends on how you want to work with the data. It is recommended that you avoid designs requiring you to transfer data in a custom object-oriented format, because doing so requires custom serialization implementation and can create a performance overhead. Generally, you should use a more data-centric format, such as a DataSet, to pass the data from the data access logic components to the business layers, and then use it to hydrate a custom business entity if you want to work with the data in an object-oriented fashion. In many cases, though, it will be simpler just to work with the business data in a DataSet.”
Note that what it advises is to use datasets to pass data between the data access logic components and business layers. You should not misinterpret it as between all layers. Before discussing the suitability, let’s identify what’s passed in-between these components.
The responsibility of a data access layer is to act as a façade to the business logic layer. It encapsulates all the functionality to work with data sources. So the datasets are closer to the data access layer in the sense they are meant to model data source.
The business components are the ones that model the actual problem scenario. They encapsulate the business concepts and logical implementations of them. This means custom objects, which are actually models of business entities, are closer to the business logic components.
What pass in-between these two layers are requests for data from data source and the responses to those requests, updates to data source and the state of the data source.
We could use objects that are closer to business components and let the transformation take place in the data access layer or we could use objects which are closer to the data access layer and let the transformation happen in the business layer.
So far I think I have made it clear that use of datasets does not violate object oriented concepts. So now let me discuss why they say datasets are more suitable.
Often in enterprise applications, business logic components and data access components are separated physically. Ability to separate layers from processes / physical layers is one of the advantages in a good design. There are certain concerns and challenges which the design of objects that are used to transfer in-between these boundaries should address such as performance and serialization issues.
If we are to use our own custom object we should make the extra effort of designing and developing our objects so that they are suitable for these scenarios. But as you know reusing is one of the main concepts behind OOD & OOP. So given the option between a custom object which we need to develop above additional features and the datasets which already has a proven implementation advising to use datasets makes lot of sense.
Let’s not forget that there could be exceptions. In a simpler application which would never grow into multiple physical tiers this could be an overhead. As I mentioned our model should adequately manage the complexity of the problem. It shouldn’t complicate things more than they are nor should it take things too simple.
Hi, Ludmal, I wonder how u gonna say Football 24/7's architecture is bad and a mess. I also studied Football 24/7's architecture and learned lot of things including using typed datasets in a distributed architecture. They had implemented those applications in a really nice architectural manner.
ReplyDeleteOnly problem with that was its business layer is coupled with the database little more. But I don't think that’s a big issue to give that up.
But I don’t like to use datasets or typed datasets in web applications since its overhead is high.
yo madhawa, i didnt say football 24/7 got a bad architecture,i said i gave up studying becoz it used the typed datasets in the UI, I know its good DVD with some really good help feautures.. but what i dont like to see is messing with the UI layer. As u mentiond I personally dont like to use typed datasets in the UI layer nor the business layer. But as mahasen explaind we could use dataset/xml etc... from the datalayer to business layer. But if u read Application Architecture for .Net: Designing Applications and Sevices you'll get to know why we shouldnt use Custom objects to represents data. stick to this discussion & bring ur ideas..
ReplyDelete*Offending comment was removed
ReplyDeleteI want to stress that I do not wish to tolerate imprudent comments from people who aren’t matured enough to identify civilized from uncivilized.
Come on now fellows; don’t make this a forum to settle your personal disputes. Lets have a civilized conversation about Microsoft® Patterns and Practices expressing our own views with an open mind with the intension of improving our own knowledge while allowing who ever reads this to benefit from it as well.
And if you guys really want to discuss about this football 24/7 DVD share it with me as I don’t have a clue for what is in it.
Further to my previous comments, I’d like to add following in favor of Microsoft’s comment “...In many cases, though, it will be simpler just to work with the business data in a DataSet”.
Read it carefully again... emphasize on the word simpler. Does it say better? No. it says simpler. Why simple? you may ask. Because KISS (Keep It Simple, Stupid) and SMILE (Simple Makes It Lot Easier) are basic principals behind application design.
Let’s keep in mind that among many advantages like reusability manageability and extendibility object orientation also has few disadvantages like high resource requirements. So if you add any thing unnecessary to your design it is these disadvantages that you elevate.
A common mistake that most novice architects make is making things too complex than needed. Managing complexity is an art that talented and experienced architects excel in. in OOD our goal should be to model the existing problem so that we could solve the existing problem. Not to create new problems so that we could enjoy solving them. Not to apply neat new patterns we just learned in to a problem that doesn’t exists. We model real world entities and concepts, any thing in addition to that should only be added to facilitate adoption to the infrastructure.
An architect is not a person who just designs application; he makes crucial decisions on things like potential growth of the application, areas in which the requirements could change, best equations for resources, time and features (some times with all three values are given as constants! – time could be expanded and resources could be shadowed) etc. So his / her design trades with all those aspects as well.
For example if our application is a simple online kiosk, which displays search results in a grid, which would reside in our only server in which we have both IIS and SQL Server. Why should we make biding data to that grid any complicated than filling a dataset using a DataAdapter and setting the data source in the code behind itself? I believe any more work would just be an overhead.
If we have a well normalized data base design, entities in the database would most probably resemble our business entities. When a typed data set is created to model that, with all that neat relationships and functionality, all which is left for us is to weave the concepts in to solve our problem. So why should we waste time and money developing another layer to represent the same thing unless it is enforced by complex scenarios and infrastructure requirements?
Sure; you may say that’s the approach of an elementary level developer. I say if there’s an elementary level problem, it should be solved with an elementary level solution. Should we let our arrogance waste precious development time? Of cause an elementary level application today has the potential of growing in to an enterprise application. It is the responsibility of an architect to foresee that potential and tailor an adequate design within the triangle of time, resources and features.
Both of you have mentioned that you don’t like to use datasets. Any one can have their personal preferences to technology. But I do use datasets in all three layers depending on the requirement. I find it really simple to work with them and they enable me to finish small scale applications within hours which other wise could have taken days if not weeks. There are instances where I don’t use them at all but it’s not based on personal preference but based on the requirement and the nature of the application.
Oops I forgot to mention about the Typed Datasets in the above comment. (DataSet, XML, etc… ‘etc’ couldn’t do it). What I was trying to explain is from the Mahasen’s post (his first comment) the conclusion I got is to pass DataSet, TypedDataSet, XML etc.. to the business layer & pass the Business Entities, Custom Collections, etc.. etc to the UI Layer. Check the simple diagram.(http://ludmal.blogspot.com ) “There are instances where I don’t use them at all but it’s not based on personal preference but based on the requirement and the nature of the application.” I totally agreed with you. KISS (its nice saying) is the best approach while we architecture our software’s. Always the solution has to be simple. I just read a nice article about the DataSet vs collections (thought it would be helpful to this thread) http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx and found a nice comparison table about DataSet, Typed DataSet, & Custom business Entities.. you can find it here.http://msdn.microsoft.com/msdnmag/issues/05/08/CuttingEdge/default.aspx?fig=true#fig3 .
ReplyDeleteThere are certainly performance differences between DataSets and custom
collections. Isn’t it easier to solve a problem in a real OOD manner? Anyhow it’s totally not about the personal preferences; it’s just a matter of complexity of the application & the problem we’re trying to solve. I have seen many posts & arguments about the Dataset vs custom Collections. But the best thing is to know the pros & cons, and to apply them to the relevant situation. With .Net 2.0, features like Generics & IBindingList will give the developer opportunity to generate collections more quickly & effectively.
I would like other developers to share their comments with us so that we, as a small .net community can go ahead & find better .Net solutions for more complex problems.
While I was reading about the DataSet last night I found some good pros of datasets. (http://objectsharp.com). I summarized it & posting here it might give you some idea about the datasets.
ReplyDelete• They are very bindable.
This is less of an issue for Web forms which don't support 2 way databinding. But for Win forms, datasets are a no brainer. Before you go and say that custom classes are just as bindable and could be, go try an example of implementing IListSource, IList, IBindingList and IEditableObject. Yes you can make your own custom class just as bindable if you want to work at it.
• Easy persistence.
This is a huge one. Firstly, the DataAdapter is almost as important as the DataSet itself. You have full control over the Select, Insert, Update and Delete sql and can use procs if you like. There are flavours for each database. There is a mappings collection that can isolate you from changes in names in your database. But that's not all that is required for persistence. What about optimistic concurrency? The DataSet takes care of remembering the original values of columns so you can use that information in your where clause to look for the record in the same state as when you retrieved it. But wait, there's more. Keeping track of the Row State so you know whether you have to issue deletes, inserts, or updates against that data. These are all things that you'd likely have to do in your own custom class.
• They are sortable.
The DataView makes sorting DataTables very easy.
• They are filterable.
DataView to the rescue here as well. In addition to filtering on column value conditions - you can also filter on row states.
• Strongly Typed Datasets defined by XSD's.
Your own custom classes would probably be strongly typed too...but would they be code generated out of an XSD file? I've seen some strongly typed collection generators that use an XML file but that's not really the right type of document to define schema with.
• Excellent XML integration.
DataSets provide built in XML Serialization with the ReadXml and WriteXml methods. Not surprising, the XML conforms to the schema defined by the XSD file (if we are talking about a strongly typed dataset). You can also stipulate whether columns should be attributes or elements and whether related tables should be nested or not. This all becomes really nice when you start integrating with 3rd party (or 1st party) tools such as BizTalk or InfoPath. And finally, you can of course return a DataSet from a Web Service and the data is serialized with XML automatically.
• Computed Columns
You can add your own columns to a DataTable that are computed based on other values. This can even be a lookup on another DataTable or an aggregate of a child table.
• Relations
Speaking of child tables, yes, you can have complex DataSets with multiple tables in a master detail hierarchy. This is pretty helpful in a number of ways. Both programmatically and visually through binding, you can navigate the relationship from a single record in master table to a collection of child rows related to that parent. You can also enforce the the referential integrity between the two without having to run to the database. You can also insert rows into the child based on the context of the parent record so that the primary key is migrated down into the foreign key columns of the child automatically.
• Data Validation
DataSets help with this although it's not typically thought of as an important feature. It is though. Simple validations can be done by the DataSet itself. Some simple checks include: Data Type, Not Null, Max Length, Referential Integrity, Uniqueness. The DataSet also provides an event model for column changing and row changing (adding & deleting) so you can trap these events and prevent data from getting into the DataSet programmatically. Finally with the SetRowError and SetColumnError you can mark elements in the DataSet with an error condition that is can be queried or shown through binding with the ErrorProvider. You can do this to your own custom entities with implementation of the IDataErrorInfo interface.
• AutoIncrementing values
Useful for columns mapped to identity columns or otherwise sequential values.
First of all I’d start by commenting on some of your statements in yesterdays post. (No offence meant – pardon if my words are too harsh)
ReplyDelete“Oops I forgot to mention about the Typed Datasets in the above comment. (DataSet, XML, etc… ‘etc’ couldn’t do it). What I was trying to explain is from the Mahasen’s post (his first comment) the conclusion I got is to pass DataSet, TypedDataSet, XML etc...”
TypedDataSets are inherited from DataSet class, so in our context by the laws of polymorphism you do not have to mention TypedDataSets again. When you say DataSets you are already referring to TypedDataSets as well. The article you referred mentions it separately because the specializations of TypedDataSets are discussed.
Talking about that article, it seems that it has missed out the sophisticated transaction handling capabilities of datasets. May be because he thought it’s not relevant for data transferring but I still believe it should have been discussed in favor of DataSets. It also does not mention patterns and practice recommendation of hydrating a custom entity using the dataset, which preserves the true object orientation at the business components level. There are few more contradictions in that article but since it’s not our primary goal to criticize it I’ll refrain from doing so.
On the other hand you could have done a better refinement to your previous post by describing the process of passing XML across tiers briefly. Especially in-between business logic components and data access layer. Hope you weren’t referring to objects that hold xml as it would be another case of you dual referencing the same scenario. And I also rule out webservices on this regards as it is more a business component to business component or business component to UI layer transferring. They use xml as their transferring media (Ways of passing raw xml is another interesting topic in its own which we should discuss later in detail)
You comment me saying selecting of technology should be done based on requirements not on personal preferences and say “...I totally agreed with you.” And later in the post you say “Anyhow it’s totally not about the personal preferences; it’s just a matter of complexity of the application & the problem we’re trying to solve” putting forward another question which I may answer in due course. But in your earlier comment you say “...I personally dont like to use typed datasets in the UI layer nor the business layer” I find these two statements to be in contradiction to each other. Is it that you changed your personal views or I misunderstood you once? (Hope not twice)
Towards the end of the post you state “But the best thing is to know the pros & cons, and to apply them to the relevant situation.” Stating about the use of custom objects and datasets; Which, I feel is a shift away from the stance you held when you started this thread. It could very well be that I misunderstood you. I’d like others to comment on this.
In your latest post you go on to complement DataSets and TypedDataSets almost as if you are writing an article on them. I do not want to believe you started this conversation without knowing these things. Had you not known these facts till you read this specific article, I think you had no ethical right to say “...I personally dont like to use typed datasets in the UI layer nor the business layer”. What you should have said is some thing like – “I do not know of the advantages of using datasets neither in UI layer nor the business layer”. More over I find you shifting from our topic of best practices to talk about DataSets. If you do agree with me on my posts you should state so and continue on the topic in hand. If you wish to talk about datasets we shall talk in a new thread. I think for comments like you previous, your own blog is a much suited forum. We aren’t co composing an article here. This is a technical conversation to logically reciprocate concepts in Microsoft patterns and practices. Others please comment on this.
Deviating from those comments of yours, which I find to be contradictory, I’d like to answer your question, “Isn’t it easier to solve a problem in a real OOD manner?”, I would like you to define what you mean by “real OOD manner” to give an detailed answer. But for now based on my definition of object oriented design the answer is not always. I’d explain with samples when you provide your definition.
Yes. Certainly Generics but more or less the consumer-provider model involving the IBindingList interface would make the life of developers easier. But it has no effect on the role of DataSets and their use in applications designed for framework 2.
I do agree with your last invitation and do urge other developers to share their view.
I’d also like to escalate that I feel this conversation is deviating from our original topic, which you started by raising a concern about Microsoft’s architectural suggestion and I replying defending that with logical facts. But your last post does not seem to put forward a new issue nor does it challenge the logics in my comments.
This is some thing I do not wish to let happen. We should be reciprocating technical concerns rather than stating glamorous slogans without any logical facts to back them up.
So as a measure to move this conversation forward in a productive way, I request you to explain your view of object oriented application design in detail.
If we both agree on an informal definition we could move forward in to discussing Microsoft guidelines for application architecture with “Application Architecture for .Net: Designing Applications and Services” article as a general guide line. We could start each new issue in a new post so things don’t get to messy.
I also appreciate if you write a descriptive summary on the contents together with the links to the articles you refer but not a downscaled version of the entire article. So readers wouldn’t have to read an entire article to follow this thread.
I eagerly invite other interested bloggers to participate in this conversation in a semi-professional manner (I discourage complete informality to safeguard the dignity of the subjects that we talk about and opt out complete professionalism so that our views could be clearer.)
(No offence meant – pardon if my words are too harsh)
ReplyDeleteI want you to know that when I mentioned “DataSet, XML, etc… couldn’t do it” (PLEASE note the “couldn’t do it” part), I received lots of personal comments saying that why you don’t want to use typed datasets - that’s why I said “‘etc’ couldn’t do it”. When we are talking about datasets I believe that we have to declare them separately i.e. if I say to a developer to use Datasets he will be wondering what to use. Still I don’t see it as a major issue by declaring them separately.
About the articles I mentioned, I just wanted to know about the differences between DataSet/Custom Entities. It’s just “see also” stuff. If somebody wants more info, they should read that. I didn’t want to extend my post & to make it dreary for the readers.
I think what we’re having here is a discussion & not a argument coz since we’re talking about the same subject in harmony and as I told you before I just want to discuss about the Microsoft Patterns & Practices - not to criticize it.
“...I personally don’t like to use typed datasets in the UI layer nor the business layer” - I know what I said. but while we’re discussing, I came to a conclusion that it’s totally not about the personal preferences; it’s just a matter of complexity of the application & the problem we’re trying to solve. We’ll get conclusions while we’re discussing. That is why we’re discussing. Isn’t it?
I do agree with you and I apologize for it, that I was slightly out of the track on discussing Microsoft Patterns & Practices. I really don’t want to pinpoint things and defend myself. It doesn’t make sense to all of us. No one will get benefits from it. I’m back on track I guess with Microsoft P&P. And I also wanna keep posts small & simple (KISS). Lengthy posts are really hard to follow & it makes dreary for the readers.
What is real OOD? The fact is that true object oriented design is to map the programming world to the real world while trying to model the solution as it was in the real world. In object oriented design complexity is managed using abstraction. If we’re trying return a Customer Dataset instead of a CustomerCollection will it be a true OOD?
What Microsoft saying is “Custom business entity components are not a mandatory part of all applications? Many solutions (especially ASP.NET-based applications and business components) do not use custom representations of business entities, but instead use DataSets or XML documents because they provide all the required information and the development model is more task and document- based as opposed to object-oriented.”
I need comments about this & the same time we’re still inviting other developers out there to share they’re ideas with us. It will be beneficial to all of us.
I do not quite understand your first paragraph. But as you state it’s insignificant – I guess its fine. Your second paragraph seems to be referring to me saying about briefing articles. What you say is fair enough but what I was referring to is you making entire posts on a single article.
ReplyDeleteYes it is a discussion, not an argument nor a public bulletin board. But it didn’t seem that way in previous posts of yours. That’s why I had to make my last post. The conversation wasn’t leading any where and it was completely out of track.
Yes. We discuss things to arrive at a conclusion. But when you agree to some thing you should state I agree without going on repeating the same stuff as the other in your own words. Other wise how come that be considered as the conclusion?
I’m glad that we are back on track and hope to stay that way.
I would like to refine your definition as “An object oriented software design is an abstract model of entities and concepts of the problem (not necessarily of real world) and adaptive components to the target domain in which the system would exist” with your agreement on this definition as a condition, the answer to your question is,
It’s not a customer dataset that’s going to represent a customer collection object but a customer datatable object. (dataset contains a collection of tables and relationships representing many entities). In a normalized database (which should be if well designed) a single row of a table (in our scenario customer table) represents a problem domain entity. There by a table represents a collection of entities. (Dinesh, who I believe is following this thread, should be able to shred better light on this argument) and the relation ships of that table with other tables in the database represents the problem domain relationships. A datatable is a abstraction of a database table. There for in our scenario it certainly does represents a collection of customers and could be used in place of a customercollection. Also a datarow in that table represents a customer while the relationships account for aggregations and compositions. All that is left to do in a typed dataset is to implement required methods and events to adopt them directly to business domain.
“Custom business entity components are not a mandatory part of all applications. Many solutions (especially ASP.NET-based applications and business components) do not use custom representations of business entities, but instead use DataSets or XML documents because they provide all the required information and the development model is more task- and document- based as opposed to object-oriented.”
This is exactly why I answered not always for your question in my last post. Object orientation should be used to address complex solutions or solutions that has high probability to become complex. For straight forward applications that involve little business logic but could involve a great deal of data representations and repository, object orientation could be a great over head. For an application of that sort what is required is data transformation in between data repository and UI with minimum intervene while transferring. Majority of the transformations could take place at the data access level itself. And in certain cases ease of development also count. For example binding a grid to a dataset is the easiest way to do it for an application that allows a user to view and edit related hierarchical data. As you agreed with me (for what I understood) “it’s just a matter of complexity of the application & the problem we’re trying to solve” the technology used should be selected based on that. That applies to object orientation as well.
If you agree with me on this, please state so that we could continue to another topic. If not we shall discus things in more detail so with input of us both we could arrive at a conclusion.
I’m joining hands with you to invite others to join in and contribute with their valuable input.
Yep mahaesn, I agreed. But it would be better discussion if some other developers also share their view on that topic. So what are we going to discuss….Any ideas…
ReplyDeleteI’m planning not to do conversations unless some one requests me to. But if you start up some thing in your blog, I will contribute to it with pleasure.
ReplyDeleteYour always welcome. Currently im busy on a tight project. I will start a thread in mine after some time. Cheers.
ReplyDelete