Так что, как и большинство новых разработчиков .NET, вы начинаете передавать DataSets повсюду, и, несмотря на то, что все работает, это кажется неправильным.
Следующим шагом обычно является создание объектов сущностей, которые расширяют базовый класс DAL, поэтому у вас есть, например,
public class User : UserDAL
{
//User specific methods
}
public class UserDAL
{
//Bunch of user specific properties
public User Load(int Id)
{
//Some low level ADO calls
}
private User LoadFromDataSet(DataSet ds)
{
//Load entity properties from DataSet
}
}
Пользователь расширяет объекты UserDAL, которые имеют низкоуровневые вызовы доступа к данным, используя ADO.NET.
Отсюда вы узнаете, что эта реализация означает, что вы привязаны к уровню доступа к данным, и вы используете отдельную сущность, объект доступа к данным и интерфейс DAO для насмешки или для простой замены DAO в случае необходимости. т.е. * +1008 *
public UserDAO : IUserDAO
{
//Data access Functions
}
С использованием обобщений и рефлексии или хорошего ORM вы можете облегчить некоторые из наиболее распространенных операций CRUD для доступа к данным, т.е.
Public UserDAO<User> : BaseDAO<User>, IUserDAO
{
//BaseDAO deals with basic crud so more custom data access methods can go here
}
Так что в основном это то, где я сейчас нахожусь, кроме некоторых других полезных практик, таких как использование IoC для разрешения конкретного IUserDAO, который я хочу. Но хотя я вижу преимущество этой структуры, мне также кажется, что я скучаю по старым вызовам метода User.Load (1).
Что мне было интересно, так ли плохо было бы внедрить мой IUserDAO в сущность «Пользователь» и взять ли это на себя все основные операции CRUD?
Насколько я понимаю, в качестве POCO у объекта User не было бы никаких проблем, передаваемых по проводам, и добавление таких методов, как Save (), Load () и т. Д., Не имело бы смысла в смысле объекта передачи данных.
Но с учетом этого мои сущности обычно имеют лениво загруженные коллекции, которые ничего не значат в смысле DTO. Кроме того, я считаю, что с WFP можно выбрать, какие свойства я хочу сериализовать, или, по крайней мере, я могу создать новое UserDTO, когда мне нужно будет отправить его по проводам.
Таким образом, помимо этой проблемы, каковы другие проблемы с включением моего объекта User в методы, связанные с DataAccess? Также может кто-то уточнить, называется ли то, о чем я говорю, активной моделью записи или это что-то еще?
РЕДАКТИРОВАТЬ:
Cristianlibardo отметил:
Что касается потенциальных недостатков, то существует большая связь с кодом постоянства, сопротивлением при отслеживании / обновлении ассоциаций, тестируемостью и запросами.
Был бы некоторый уровень связи, но я думал, что-то вроде следующего:
public class User
{
IUserDAO userDAO;
public User()
{
userDAO = IoCContainer.Resolve<IUserDAO>;
}
public User(IUserDAO userDAO)
{
this.userDAO = userDAO;
}
//DAL methods
}
Таким образом, связь должна быть минимальной, а что касается тестируемости, я не вижу в этом проблемы, поскольку я могу просто ввести фиктивный DAO в сущность.
Благодаря Брайану Хасдену, это действительно хорошие ресурсы, но я думаю, я просто хотел оправдать то, что я собирался сделать. Спасибо за предоставленное обоснование.