We Keep Coding

Property name of output model API

Good morning, guys, I need some advice.
I’m creating the output templates for my APIs but I’m very confused about the name of the classes.
For example, I have an entity called User.
In the output model I must return a list of User but it must not center with the entity but with another model created by me for output.
Well, I don’t know what to name this last class I told you about.
I cannot call it User because it conflicts with the real entity.
Tips?

There should be at least 3 layers of objects in your code, ViewModel, Dto and Entities.
Each layer should only be able to see the layer directly below it.
So, your service layer, can read Entities from your data layer, but if it exposes any objects, they should be in a Dto.
Then, your presentation layer (UI/API etc), will read from the service layer (DTO), and expose it's objects as ViewModels.
In many cases, this means that all 3 objects (Entity, Dto & ViewModel) have the same repeated properties, but this is to be expected, especially in smaller or newer projects.
This should then solve your naming problems.
Data layer: XXXEntity
Service layer: XXXDto
Presentation layer: XXXViewModel
This explanation is very simplified, and you could solve this problem in many different ways (you could use namespaces instead of class suffixes for example).

The guidance I try to work by is that naming should reflect intent - whereas a User just represents the concept of a 'user' in your domain, an API model is intended to be an API payload containing user information. In your position, I would consider something like UserApiModel or UserPayload.
*As an added note, for my money, the thing that matters the most here is consistency - no matter what you pick, what makes sense to you now may not be the most intuitive thing to you (or anyone else) maintaining the code later. As long as you apply your naming convention consistently across all your API models, don't stress too much about finding the 'right' one - just pick the first one that seems good enough, and keep rolling.

What is the objective of an ObjectMapper?

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.

Pulling out business logic from the data access layer

We are writing some support applications (rather small) to our ERP system.
Thus until now I am feeling that I am using the Data Access Layer for 2 roles: the business layer AND the data access one.
I am having trouble deciding what I have to move to a separate layer and if I need to. I have read somewhere that knowing when to make layer separation is wisdom and knowing the patterns is just knowledge. I have neither in adequate amounts.
So I need some help to determine what is what.
My current DAL deals with fetching the data and applying basic logic on them. For example there are methods like
GetProductAvailabilitybyItem
GetProductAvailabilitybyLot
etc.
If I needed to separate them what I would have to do?
One other matter that is in my head is that in order to normalize my DAL and make it return different entities every time (through one general get method) I would have to use DataTable as return type. Currently I am using things like List<PalletRecord> as return types.
I feel that my apps are so small that its hard (and maybe useless) to discriminate these 2 layers.
My basic need is to build something that can be consumed by multiple front-ends (web pages, WinForms, WPF, and so on).
Additional Example:
Lets talk some barcode. I need to check if a fetched lot record is valid or not. I am fetching the record in DAL and produce a method returning bool in business layer?
Then i can call the bool method from whatever presentation in order to check if a textbox contains a valid lot?
Is this the logic extremely simplified?

Based on your description, you should definitely separate both layers right now, when the application is still small. You might feel a BL is useless when you're just accessing and displaying data, but with time you'll find the need to modify, transform, or manipulate the data, like coordinate object creation from different tables, or update different tables in a single action from the user.
The example you provided helps to support this idea, although is quite simplified.
Pablo's answer does offer some good design ideas too: you should definitely use an ORM to simplify your DAL and keep it very thin. I've found NHibernate and Fluent make a very good job on this. You can use the BL to coordinate access using Data Access Objects.

Given that you are dealing with very small applications, why not just have an ORM provide all data-access for you and just worry about the business layer?
That way you don't have to worry about dealing with DataTable's, mapping data to objects and all that. Much faster development, and you would reduce the size of the codebase.
For example, NHibernate or Microsoft's Entity Framework
Now, if you will be providing data to external consumers (you are implementing a service), you may want to create a separate set of DTOs that go through the wire, instead of trying to send your actual model entities.

I am not a big fan of nTire architecture and have some good reasons for it.
Main objective for such an architecture are
Ability to work with different underlying database separation of
context - i.e. application design and business logic Uniformity and
confirmation of best patterns and practices.
However, while doing so, you also make some sacrifices such as give up provider specific optimizations etc.
My advise is, you can go with two layer architecture,i.e. Data access and business logic layer and GUI or presentation layer. It will still allow you to have a common code for different platforms and at the same time will save you from spaghetti code.

Is Business entities/objects about organizing or performance optimizing?

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.

C# Business Object Architecture question regarding Business and DTO objects

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