I don't understand why in Object Oriented development people are using some ObjectMapper class. Could you explain me what is the purpose of this kind of class? I'm also looking for documentation about it. I found a lot of information explaining how to create it but nothing about how and why to use it. Do you know where I can find a good article, blog on this (in C# if possible).
A sub-question to be sure to understand. Are ObjectMapper something used in C++?
Thank you.
Object to Object mapping is not a programming language related question.
There are plenty of useful scenarios when Object to Object mapping comes in handy.
One common scenario is when you have designed your business object model and developed your business services that deal with those objects, within your domain application layer. Now, what if you want to expose your data to any UI and/or clients? You obviously do not want to expose business objects. Here comes the mapping! You might transform your business objects to DTO’s if you’re dealing with web services. You might transform them to ViewModels if the consuming UI is an MVC application…
Hope this helps!
ObjectMapper
This mapper (or, data binder, or codec) provides functionality for converting between Java objects (instances of JDK provided core classes, beans), and matching JSON constructs. It will use instances of JsonParser and JsonGenerator for implementing actual reading/writing of JSON.
As far as I know, the ObjectMapper class is not related to C++. Indeed, it is something related to Java. Hope it helps. In either case, you can refer to below link for your knowledge,
http://www.massapi.com/class/ob/ObjectMapper.html
As #Hiren Pandya points out, ObjectMapper is a java class that helps in the serialization and deserialization of java objects to and from json.
In general, this is helpful when you have matching json properties (and structure) and you don't want to write all of that mapping code yourself.
Object mappers as a pattern (even more general) can be useful in many scenarios. Anytime you have two representations (classes) that are logically part of the same concept, you may want to copy data from one to the other.
I hope this helps, however, as I write it sounds pretty general. Maybe if you give a specific case where you feel it might be needed it would be easier to address.
Related
Anybody can explain about the difference between the
POCO and DTO objects in c# with example
and also go through the below link
in the below link having four types to transfer data from one layer to another layer
i cant under the link explanations
Four ways of passing data between layers[^]
What I have tried:
please help me out from the confusion
learn to love the POCO, and make sure you don’t spread any misinformation about it being the same thing as a DTO. DTOs are simple data containers used for moving data between the layers of an application. POCOs are full-fledged business objects with the one requirement that they are Persistence Ignorant (no get or save methods)
BTW, Patrick, I read the POCO as a Lifestyle article, and I completely agree, that is a fantastic article.
YOu can check more details form here http://rlacovara.blogspot.com/2009/03/what-is-difference-between-dto-and-poco.html
I don't know the difference between Business Entities and Business Objects
But what I have is a class that has some properties and I'll add an IsValid method later.
That's what Application Architecture Tutorials taught me
But it just hit me, what's the difference between using this approach and just sending/receiving my data through my layers without storing them in objects .. and when I add an item to the database, instead of creating an object of the item's type then store it and send it to the BLL or the DAL, I would just send the information I just collected as it is, as an argument to my BLL methods!
I'm sorry if my question is a bit confusing. But I hope that you'll excuse me as this question and the application architecture is a just a very big ocean ..And I'm LOST! =S
P.S: I added the technologies I'm using, Hoping it will help you understand my environment
The bottom line is that either way can work--it's possible to pass your data around as a series of parameters and make it work. There are even situations where it might be more derirable to do it that way (e.g. a really simple application).
That said, it's generally accepted that it's easier to code and maintain an object or set of objects that represent your data than it is to pass multiple (possibly many) parameters through every method call and layer of your application.
This concept is called encapsulation, and is one of the core principles of Object Oriented Programming. A quick google will probably answer your question more completely.
When using simple DTOs in various scenarios I have frequently run into the same kind of problem and I always wondered whether there's a better way to deal with it.
The thing is, I have a business object, e.g. Asset which has a bunch of properties, child objects and calculated fields, some of them expensive to calculate in sense of time, some of them huge in sense of data amonut. I need to use a different flavor of this object in various screens in the UI, e.g.
in a tree where there is a hierarchy displayed and I don't need much more than the display name
in a grid where I'm showing just a couple of properties
in a detail pane where there's a big subset of available information, but still some of it (like mapped objects) is shown only on demand
To be able to achieve optimal performance with this scenario, I have always created different DTOs for each context, only containing the subset of information which is actually used in that context. While being a resource-optimal solution, this leads to couple of problems :
I have a class explosion with huge number of DTO classes
I have quite a hard time coming up with different names for the same thing like AssetDtoForGridInTheOverviewScreenInTheUpperPaneAboveTheSplitter, not to mention maintaining them later
I am frequently repeating myself in the transformation methods, because there are properties that are used by most of the DTOs but not by all of them (therefore I can't put them into any superclass and reuse the transformation logic)
The technology I'm using is ASP.NET SOAP WebServices and C# 3.5, but I think somehow this could be a language-agnostic problem. Any ideas are welcome..
This is a known problem with DTOs. It's described in this otherwise mediocre articule on MSDN. To paraphrase: DTO is the most versatile n-tier data access pattern, but it also requires most work.
You can address some of your issues with mapping by using convention-based mapping, such as AutoMapper.
When it comes to class explosion, could it be that you are using too flat data structures?
This can be difficult to tell because DTOs naturally include a great deal of semantic repetition that turns out to not be logical repetition at all. For example, even if you have semantically similar types, if one is a ViewModel and the other is a Domain Object, they may share semantic structure, but have vastly different responsibilities.
If, on the other hand, you have a lot of repetition in the same application layer (e.g. UI), you may be violating the DRY principle. In this case, it may often help to encapsulate related data in what starts out as a flat data structure into a separate class. In most UI frameworks I'm aware of, you can still databind a flat display to a hierarchically structured class.
The problem of class explosion is inherent to the DTO approach, there probably isn't much you can do about that. Be careful not to mix your view-model with your DTO model. Your DTO's should only be used to get the data from your data tier to your front end and not for presentation.
With the advent of .NET 3.5 you can choose to implement some basic, more coarse grained DTO's and replace your ViewModel with an anonymous type which you can dynamically create off your DTO's. I found this to be avery flexible solution.
Regarding your naming conventions, it is probably useful to group your DTO's into scenarios and put them in a corresponding namespace. For example Solution.AssetManagement.Asset and Solution.AssetReporting.Asset
Background
We have our own Business Object Architecture, a much lighter (...and loosely based on, but does'nt actually use...) version of the "CSLA" business object framework with similar usage, validation, inclusive DAL etc. All code is generated (stored procs and Business Objects are creaed using CodeSmith)
The Business Objects are quite rich with regards features to Get Objects, Lists with filter sort parameters to return Objects and Generic Lists.
This architecture may not subscribe to one particular or popular architecture and purism, but its works well for us and has reduced a lot of manual coding.
The one thing we find a lot, especially when integrating with other systems (3rd party, Flash or Silverlight etc) is the requirement for contextualised "Basic Objects" or Data Containers that can be easily serialized and supplied across webservices etc for a specific purpose.
Looking around SO and the web, the Term DTO comes up a lot. We have created these Basic objects within a Dto namespace, these objects are basic objects that represent basic or specific versions of Business Objects but have no features except Constructors that accept either a DataRow or Business Object to populate the "Dto" object.
Questions:
1) Is calling this a "DTO" object correct?
2) Rather than having constructors to provide the data and set the object properties, should this population code be in a different class, some kind of "Helper Class"
Any comments on terminology and naming conventions for what I am trying to do?
Thanks
1) Yes.
2) I see no big problem, allthough you kind of limit the use of the DTO. But again I see no big problem with it. There is a mapping framework you could use to do this for you which you can find here http://www.lostechies.com/blogs/jimmy%5Fbogard/archive/2009/01/22/automapper-the-object-object-mapper.aspx
I was reading the book "Expert C# 2005 Business Objects".
The book describes various base classes to be inherited by various classes to solve real-world problems.
But the book does not provide examples of all those classes.
Can anyone give me all of those examples (with reason) to better understand CSLA?
For example, Which real-world objects are to be considered as Read-only Root Objects (Student/Product/Order, etc.)? And Why?
The ProjectTracker sample (which can be downloaded on the CSLA downloads page) has examples of all the main sterotypes used in the CSLA books.
Chapter 6 in the book (Object Orientated Application Design) gives an overview of the design process of business objects & Chapter 8 (Business Object Implementation) gives the actual implementation of the Project Tracker objects.
In terms of your specific query - I haven't often used "Read-only root" objects. However, I often use "Read-only list root" objects though. An example would be: I have a list called ProductInfoList, which has a read-only child ProductInfo. This would be returned to the user either in a ListBox, or from a search result, etc.
Hope this helps!
I would also recommend checking out our CSLA 3.8 templates. I had this same dilemma when I was learning CSLA. He does provide sample snippets of what each BO Type should look like but I don't find this very helpful to visualize. You could take a look at our templates and run the quick start against one of your databases that you are familiar with and modify the different BO Types per table to get a better understanding of how CSLA works.
Here you can find what you need:
http://www.lhotka.net/cslanet/download.aspx (see Framework, test, samples)
But before that take a look at this article:
The CSLA Framework; what is in it for me?