エンティティオブジェクトをデータ転送オブジェクトとして使用することは良いことですか？

It is up to you.。

ほとんどの人は、それは良い習慣ではないと言うでしょうが、場合によってはそれで済ませることができます。

EFは複数の理由からDDDとは相性が良くありませんでしたが、特に目立つのは2つです：エンティティにパラメータ付きのコンストラクタを持つことができないことと、コレクションをカプセル化することができないことです。ドメインモデルはデータと振る舞いの両方を含むべきものなので、DDDはそれに依存しています。

ある意味、EFでは貧弱なドメインモデルを持たざるを得ず、この場合、エンティティをDTOとして使用することができます。ナビゲーションプロパティを使用する場合、いくつかの問題に遭遇するかもしれませんが、それらのエンティティをシリアライズして、ワイヤ上で送信することができます。しかし、実用的ではないかもしれない。送信する必要のないプロパティを持つ各エンティティのシリアライズを制御する必要があります。もっと簡単な方法は、データ転送のために作られた別のクラスを設計することです。AutoMapper](http://automapper.org/)のようなライブラリは、この目的のために作られたものです。

例えば 例えば、以下のような定義の Person というクラスがあるとする。

public class Person
{
    public int Id { get; set; }
    public string FirstName { get; set; }
    public string LastName { get; set; }
    public DateTime DateOfBirth { get; get; }

    // plus a bunch of other properties relevant about a person
}

従業員のリストをどこかに表示したいと仮定すると、 Id, FirstName, LastName だけを送信するのが現実的かもしれません。しかし、それ以外の無関係なプロパティはすべて送信しなければなりません。レスポンスの大きさを気にしないのであれば、それほど大きな問題ではありませんが、一般的な考え方としては、関連するデータのみを送信するのがよいでしょう。一方、人物のリストを返すAPIを設計する場合、すべてのプロパティを送信する必要があるため、エンティティをシリアライズして送信することが理にかなっている場合があります。この場合、DTOクラスを作成することは議論の余地がある。人によっては、エンティティとDTOを混ぜるのが好きな人もいれば、そうでない人もいます。

更新された質問に答えると、EFはORMです。その仕事は、データベースのレコードをオブジェクトにマッピングすることであり、逆もまた然りです。EFを通過する前と後のオブジェクトで何をするかは、EFの関心事の一部ではありません。また、そうであるべきです。

いいえ、そんなことはありません。

理想的には、DTOは永続性リポジトリ（別名、データベース・テーブル）と一致することです。

しかし、ビジネスクラスは必ずしも一致するわけではありません。データベースで持っているクラスに、さらにクラスを追加したり、分離したり、結合したりする必要があるかもしれません。アプリケーションの規模が小さいうちは、このような問題はあまり起こらないかもしれませんが、中規模から大規模のアプリケーションでは、このようなことが頻繁に起こるでしょう。

もうひとつは、DTOは永続性を扱う何らかの分野の一部であり、ビジネス・レイヤーはそれについて何も知るべきではないということです。

実はとても悪い考えなのです。Martin FowlerにLocal DTOに関する記事があります。

簡単に説明すると、DTOパターンはプロセスの外側でデータを転送するために使われ、同じプロセス内の層間では使われないということです。