2

В нашем решении мы имеем бизнес-объекты, как это:Как использовать структуру сущностей с бизнес-объектами

[Serializable()] 
public class Vendor : Recordable 
{ 
protected int vendorID; 
protected string vendorName; 
protected string vendorNumber; 

public void Save() 
{ 
    //call to sql stored procedure using ado.net to save 
    dbhelper.addSPParam("name",vendorName); 
    dbhelper.addSPParam("number",vendorNumber); 
    dbhelper.addSPParam("id",vendorID); 
    dbhelper.executeSP("sp_name"); 
} 

Vendor(int id) 
{ 
    //call stored procedure to get vendor data by ID 
    this.vendorID = reader["vendorID"]; 
    this.vendorName = reader["vendorName"]; 
    this.vendorNumber = reader["vendorNumber"]; 
} 

Наш код привязан к ADO.NET, но мы хотели бы использовать рамки сущности для запроса вместо записывая все вручную. Мы хотели бы сохранить некоторые хранимые процедуры, потому что в них есть бизнес-логика, но большинство вызовов хранимых процедур мы хотели бы использовать вместо этого.

Как мы можем сформировать наш проект для использования сущности framework, некоторых хранимых процедур и добавления модульных тестов (ни один из наших тестов не проверен)?

Любить любые идеи.

+0

Ничего себе, это довольно широкий вопрос. Во-первых, эти классы вообще не являются платформой Entity Framework; Entity Framework использует свойства классов моделей, а не поля, и не использует функции для связанных объектов. Кроме того, Entity Framework обрабатывает Save, он не передает его объекту. Было бы непросто создать классы для сущностной структуры, которые будут схожи с этим, но изменение этих классов будет практически таким же, как создание новых классов. – Claies

+0

Это довольно широкий вопрос, но, учитывая ситуацию, в которой вы находитесь, я бы сказал, начните с нуля. Если ваш текущий код не протестирован, его также, вероятно, очень сложно проверить. –

+0

Ужасный код. Это не бизнес-объект, это DAO. Я поддерживаю предложение «начать с нуля». Также прочитайте немного о принципах SOLID. – MikeSW

ответ

0

Этот вопрос действительно слишком широк, вам нужно попытаться разбить его на более мелкие, ответные части (некоторые из которых, вероятно, будут дублировать).

Этот ответ вполне может быть удален, так как это скорее большой комментарий, чем прямой ответ.

Сказанное, я бы начал с создания тестового проекта для проверки любого подхода к копии тестовой базы данных. Это позволит вам выполнить любые настройки, которые могут потребоваться, чтобы заставить EF работать с вашей базой данных, прежде чем вы слишком глубоко укоренились в своей существующей базе кода.

Вам необходимо знать, как позвонить stored procedures.

Вы предположительно собираетесь использовать database first approach.

Для модульных тестов вам необходимо выбрать платформу тестирования (MS, NUnit & XUnit кажется наиболее популярным).

Возможно, вам понадобится насмешливый каркас (Moq, NSubstitute и т. Д.) До write tests that don't hit the database.

Возможно, вы также захотите изучить инжекцию зависимостей и контейнер IOC (Unity, Castle Windsor, Ninject), чтобы помочь в инъецировании зависимостей, если вы собираетесь начать разбивать свой код на интерфейсы/зависимости, чтобы облегчить тестирование.

Вы хотите начать изучать использование интерфейсов, если вы еще не сделали этого, чтобы отделить проблемы вашего кода и облегчить насмешку над тестированием.

Из вашего кода не совсем понятно, как вы используете защищенные поля в своем классе, как только вы их прочитаете из базы данных, вы также можете посмотреть что-то вроде automapper, чтобы помочь в сопоставлении между сущностями DB и вашим BL объектов.

Смежные вопросы