We Keep Coding

Mapping DTO to Entity

I'm trying to map DTO's to Entities. When I searched it online I noticed lots of references to AutoMapper and just as much feedback about how it is not a good way to do this.
Also I couldn't find any newly dated sources, one question complaining about how there are no "new" sources is 4 years old.
One of the sources I found, which looked really promising was this
https://rogerjohansson.blog/2013/12/01/why-mapping-dtos-to-entities-using-automapper-and-entityframework-is-horrible/
and I couldnt get it working either.
So, basically situation is like this.
I'm trying to do an integration about orders by using wcf. (A whole another case)
I have an order dto and related dto's are orderline, customer, customeraddress, orderadress. Some more will follow later.
Since these are essentially database tables, main "table" is Order. It acts as the header, orderline and others are self explanatory. I'm sure everyone came across something like this before.
I created Dto's according to their counterpart entities.
What I'm told to do is;
a) Convert (or as terminology goes, map?) these DTO's to Entities
b) Add the entity to dbcontext and savechanges.
So, can anyone point me in a good direction on solving this situation?

We have a similar project as you. Instead of WCF we use Model classes from MVC, but finally is the same idea: to convert from one object to another. I cannot disagree more about AutoMapper. At first, we had the same doubts about its efficiency, but finally we decided to give it a try. Then, we faced some of the problems the article pointed (especially the collections of elements). Luckily, AutoMapper gives you enough flexibility to handle those special mapping conditions.
For collections we use custom mappings, which allow us to detect when we have new elements / elements to update / elements to remove
For references, we follow the rules of Entity Framework: add the FK_Id value rather than the real object.
If, for some reason, you need to add some logic on the mapping, based on some reference entities, then we use dependencyResolver (only on extreme cases, as we don't like the idea of dependencyResolver)
I think AutoMapper is easy enough to learn the basics, so you can map your objects if a matter of minutes. Plus, it gives you all the tools for the special considerations.
The article you posted explains how "Entity Framework does not like AutoMapper", but its more related on how you follow the rules of EF and AutoMapper. Entity Framework is a huge ORM and, as such, you need to follow some rules (very strict rules in some cases). Of course, using AutoMapper with the basic examples will break some rules, but once you start to get used to it, is really easy to follow the rules.
To sum up: AutoMapper saves you a lot of time, that you can invest on customize some configurations. If not, you will have to use linq projections, which in most cases will take you much more time. For example: the collection problem is solved by detecting the add/edit/delete based on Ids, which can also be handled with AutoMapper through custom mappers.

Nhibernate mapping generator that supports mapping by code from 3.2

I am looking for an NHiberate mapping generator that can generate mapping by code rather than .xml or Fluent NHibernate.
I tried NHibernate Mapping Generator, but it has no validation. Thus, the existing mapping files might not 100% correct.
Devart Entity developer doesn't support this currently.
Any recommendations?

You could try nHibernate Designer from MindScape.

Well since you are asking for a suggestion, I can say by experience don't try to use a code generator. Such kind of approach fails when the project grow, you suddenly need to add some modifications and re-generating the entities would be a pain and so on. Try to read about ConventionalMapping. It is basically a strategy in building the mapping on the fly based on some conventions generally exists in a database table vs classes naming. I did this in past and with a little effort you will be able to concentrate just on the classes and completely forgot the mapping.

Data Access Framework that addresses my needs

I'm having trouble choosing an appropriate data access framework, partly because I'm very picky with my preferences and mostly because I don't have much experience with most of them :-)
I need a framework that will allow me to easily map between the DB tables (SQL Server) and my entities, and that will handle the CRUD operations for me (for the most part).
I want my entities to reside in a separate assembly from my DAL.
I prefer using attributes for the mappings over external file like XML.
It doesn't have to be an ORM, and I want to code my entities myself.
I don't mind writing stored procedures.
The project's database won't be very big. Less than 50 tables.
I'd like some of my entities to correspond to an inner join of two tables - one for static data entered manually during development and the other with data filled during runtime - without using two entities that reference one another (the result of this join will be a single entity).
Entity Framework sounded perfect until I realized it doesn't support Enums (yet - and I can't wait for EF 5.0).
I want these entities to include Enums, and plan on using lookup tables for the enums + code generation for the enum to keep it synchronized with the database.
Linq-to-SQL seems like a good candidate, but I don't know if it copes well with my previous demands.
Using Enterprise Library 5.0 DAAB with it's RowMapper, and extending it's abilities to perform updates and inserts is also an option (but will require more coding on my part).
I plan on implementing the Repository Pattern.
How about NHibernate? Would it do? No experience there either.
I would be happy to hear all suggestions.. the more the merrier! Thanks in advance!

I think nHibernate is the way to go, although some of its main strengths (ORM, stored procedure generation, etc) are things you listed as non-requirements. Anyway, nHibernate will do everything you want it to do. Technically it does use xml mappings, but these can easily be auto-generated using fluent attribute mapping. I like this, as it IS done for you, but you get the customization too just in case you need it. Good luck!

Can you compare Fluent NHibernate with xml configuration mapping files?

What should I take into consideration if I need to choose between Fluent NHibernate and standard xml mapping files of NHibernate?
Can you compare the prominent differences that I should be aware of?

Several things and as mentioned this is possibly a duplicate question the main one I can think of is that you can change xml files without a code recompile but you cannot change mappings in fluent without recompiling something because they are by their nature compiled.
That said you can have a mappings assembly and then just patch that. Obviously whatever changes you make then need to be run through integration tests.
Aside from that Fluent Nhibernate can be confusing to NHibernate users because they mix some terms with their own so I always say you should start with XML file mappings until you totally understand whats going on then migrate to Fluent if you don't need to change the mappings without recompilation as it just reads better.
However don't forget you are then adding a layer of abstraction over the top with its own quirks which can make for interesting debugging.

Note: This is more of an opinion answer.
There's actually a 3rd option which you missed. NHibernate 3.2 shipped with it's own code mapping syntax.
http://nhforge.org/blogs/nhibernate/archive/2011/09/05/using-nh3-2-mapping-by-code-for-automatic-mapping.aspx
Personally I don't like the syntax, I'm a Fluent NHibernate fan and it works for me.
I think the only real thing to consider is what krystan already mentioned, which is the naming differences.
I personally threw in the towel with the XML mappings, and didn't pick NHibernate up again until Fluent NHibernate came out.
I don't believe you need to know anything about XML mappings, if you want to learn the XML mappings you can export Fluent mappings and look at them. But really the Fluent Mappings are dead simple.
Most problems from Fluent NHibernate steam from attempting to use Auto Mapping which maps a lot of assumptions, it's fine if you're planning on generating the DB schema, but if you've got an existing schema it's best to explicitly map them. I always explicitly write my maps tho.

MS Entity Framework VS NHibernate and its derived contribs (FluentNHibernate, Linq for NHibernate)

I just read this article about the Entity Framework 4 (actually version 2).
Entity Framework seems to offer a huge improvement over its first release. Thus, I have never ever used EF in any project, since I think EF is not mature enough in comparison to NHibernate.
NHibernate and its current contributions of FluentNHibernate and Linq for NHibernate by Ayende Rahien
My feeling is that Microsoft is solely trying to gain terrain it has lost in favor of NHibernate when the 2nd version of NHibernate came out. Nevertheless, my concerns are the followings (not in particular order):
Will EF4 tend to be less XML-verbose?
Will EF4 be compatible with underlying datastores other than just SQL Server?
What are the greatest benefits of going with EF4 instead of FluentNHibernate or NHibernate itself?
NHibernate is a great tool, I guess everyone agrees. Due to its predecessor Hibernate, we may easily find documentions and tutorials and sample applications to get acquainted with it. This is not the case for FluentNHibernate. Particularly as per the project I'm working on right now which demands that I investigate further about NHibernate and its options (FluentNHibernate for instance) in order to document the rules of usage and the best practices of NHibernate and FluentNHibernate technology. Thus, being handcuffed with VB.NET, being a C-Style developer, I can't find some syntax equivalencies in VB.NET for the examples provided, though I made my way so far.
I do believe that NHibernate is a best choice, but as a software consultant, I can't (don't want to) miss important technology changes, improvements and evolution.
Despite the bad comments I read about EF1, EF4 seems to be very promising. What you all think about both NHibernate and Entity Framework avenues? As for me, I am becoming puzzled with all that readings. I need you to bring back my head out of the water.
Thanks to you all!

I know almost nothing about EF, but a quick skim of the links provided leads me to believe that EF has no equivilent to Fluent NHibernate's Automapping functionality.
Edit: Some of the commenters pointed me to links indicating there is some automapping in EF, but it's not really clear if it's as powerful as FNH (for example, being able to automap collections of other objects).
Personally, I love being able to design POCOs in an OO manner, and letting the tool handle all the busy work of mapping to a relational database.
FNH still has the most powerful automapping capability, as far as I know.
Go to Fluent NHibernate Automapping for more info.

Will EF4 tend to be less XML-verbose?
In general, I have not seen any indication that the XML will be drastically different. Microsoft is providing a Fluent like interface to EF in v4, but it's an add on / separate download.
Will EF4 be compatible with other underlying datastore than just SQL Server?
It is compatible now and it will remain compatible going forward. LinqToSql is SQL Server only, but EF has never been SQL Server only.
What are the greatest benefits of going with EF4 instead of FluentNHibernate or NHibernate itself?
Honestly, there aren't many. There are little things here and there that are different, but in general NHibernate is still years ahead of EntityFramework, even in EFv4.
As a consultant, it is probably worth your time to become an expert in both NHibernate and Entity Framework. You will probably continue to see them both in the real world. Microsoft tends to have a short attention span when it comes to data access so it's not clear where Entity Framework will be a couple of years from now. Because it's from Microsoft, you can be sure that plenty of developers will use EF.

Take this with a grain of salt. I am not any kind of authority on ORM tools, but here it goes...
One of the biggest benefits that i see in EF is the GUI for mapping. IMO, this saves a lot of time, but is probably the reason why EF XML mappings are so verbose. They're not made to be dealt with manually, unfortunately. Whether it will change or not i don't know. What i do know is that the GUI that EF provides used to be very flaky in previous releases. And i still hear about people complaining that it isn't scaling well, especially on larger and more complex schemas where it just misses things and you end up messing with the mappings directly. My opinion is that XML maps will become less verbose as EF matures. You also have the fluent mapping support in EF, which is also helpful. Finally, another big thing is the ability to change code templates that EF generates, that is if you favor database-driven design instead of design-first approach.
Another benefit is that it comes from Microsoft and they have enough dough to make this a really dope framework. It has grown tremendously in the past few years. I think it'll be on the same ground with NHibernate in a little over a year. As of now, I think NHibernate is a better choice. It's more stable and mature. Relative easy to configure and most importantly a better performer. I think if you design wisely, a move from one to another is going to be a piece of cake.
EF is just an abstraction. I believe there are providers for Oracle, so i don't see why there couldn't be more added as it grows.