Будущие Доказательства DAL

Question

Мы находимся в начале действительно длинного проекта разработки с несколькими подпроектами.В основном, каждый подпроект будет развиваться несколько месяцев.Сам код будет разделен на несколько проектов C #, но физическая база данных будет общей для всех проектов.

Проблема заключается в удобстве сопровождения.Если мы добавим столбец в таблицу или разделим таблицу на две меньшие таблицы, нам придется вернуться и изменить наш C # DAL для поддержки этих изменений.Это неприемлемо, так как мы будем постоянно адаптировать БД в соответствии с потребностями компании в целом, а не только с потребностями одной программы.Постоянное изменение старого кода было бы бесконечной задачей.

Сотрудники нашей БД предложили другое мнение.Мы выполняем все наши CRUD с помощью хранимых процедур и используем Linq для нескольких таблиц для выполнения наших операторов SELECT.Затем, если мы реструктурируем БД через несколько лет, мы можем просто предоставить те же самые хранимые процедуры и представления и не должны изменять наш старый код.

Вопрос, который у нас возникает, заключается в том, какой ORM следует использовать для чего-то вродеэтот?EF кажется немного излишним (возможно, это не так).Разве что-то вроде SubSonic с его шаблонами T4 позволит использовать более простой (и, возможно, более быстрый) DAL?

Или, возможно, у кого-то есть идея, как сделать весь этот процесс менее болезненным?Мы не хотели бы добавлять еще один слой в наше приложение, но мы также не хотим возвращаться и модифицировать код каждый раз, когда мы вносим изменения в БД.

Редактировать 1: Поэтому, когда я сказал: «Я действительно не хочу добавлять больше слоев».Это в основном потому, что у нас уже есть несколько слоев.У нас есть представления Silverlight, модели представления, объекты BLL (через CSLA), затем у нас есть DAL и, наконец, сами таблицы SQL.

Answer 1

C# DAL... not just the needs of a single program.Весь смысл C # DAL как отдельной сборки заключается в том, что его можно повторно использовать в любом приложении .NET.Основная проблема, с которой вы столкнетесь, заключается в том, что если база данных изменяется, то DAL должен измениться (один раз), а затем все приложения, зависящие от DAL, должны быть повторно развернуты с новым DAL.У вас также есть проблема, заключающаяся в том, что DAL не может использоваться приложениями, отличными от .NET.

Хорошо, так как же вы можете централизовать DAL, чтобы вам не пришлось повторно развертывать его для каждого приложения??Подумайте, SOA.Вы можете создать сервис WCF, содержащий DAL (и, вероятно, BLL).Все ваши приложения (если вы используете веб-службы, даже те, которые не являются .NET) могут использовать эту службу.Когда база данных изменяется, вы обновляете службу WCF и развертываетесь один раз.Просто убедитесь, что вы не вносите никаких изменений!Создайте MyMethod2, если вам нужно добавить / изменить функциональность.

Примечание. Когда вы слышите n-уровень, он обычно относится к трехуровневому, где каждый уровень представляет собой отдельное программное обеспечение и обычно на отдельных серверах:презентация (UI), приложение (ваш BLL / DAL), данные (ваша база данных SQL).Эта архитектура имеет свои достоинства.

We'd rather not add another layer to our application.Итак, трехуровневый может быть не лучшим подходом в вашем случае.

neither do we want to go back and modify code everytime we make a db change Тогда то, что ваши сотрудники DBA предложили, является единственным способом.

Однако учтите это: изменениехранимая процедура так же, как изменение кода?Это в основном то же самое.Хранимые процедуры SQL часто не контролируются версиями и не тестируются, но они должны быть.SQL не обладает таким богатством, как .NET.WCF можно легко масштабировать в веб-ферме.Как только вы учтете эти и другие причины, возможно, стоит перейти на трехуровневый подход / SOA.

Это действительно зависит от размера вашего проекта, навыков персонала, будущего роста и т. Д., И это что-тотолько вы можете определить.

Answer 2

Я начал использовать BLToolkit , основываясь на информации о производительности от http://ormeter.net/

Вы можете определить свою модель в простых файлах классов, добавить некоторые методы с примененными атрибутами и получить DAL. Разделите таблицу на две части, и вы сможете сохранить исходный файл класса, создавая новые для поддержки таблиц разделения. Просто убедитесь, что вы создали тестовый проект, включающий все методы, чтобы убедиться, что все они работают с каждым выпуском

Класс

    public class DirectoryListing
    {
        [PrimaryKey, Identity]
        public Int64 Id { get; set; }
        public Int64? OldId { get; set; }
        public Int32 CategoryId { get; set; }
        [Nullable]
        public String CompanyName { get; set; }
}

Функция общего выбора или табличного значения:

[SqlQuery("SELECT * FROM Ajax_CategorySearch(@SearchString, @ResultCount)")]
[Cache(MaxCacheTime = 10, IsWeak = false)]
public abstract List<String> AjaxCategorySearch(String @SearchString, Int32 @ResultCount = 10);

Или использовать сохраненный процесс:

[ActionName("SelectById")]
public abstract Model.DirectoryListing SelectById(Int64 @Id);

Это вызовет SP DirectoryListing_SelectById

Да, и делать вещи более классическим способом тоже легко

    using (BIFDbManager db = new BIFDbManager())
    {
        var output = db.SetCommand(
            "SQL GOES HERE",
            db.Parameter("@Id", 1))
            .ExecuteList<DAL.Model.DirectoryListing>();

        totalrecords = output.Count();

        return output;
    }

Последней частью головоломки является менеджер БД, который также включает поддержку LINQ.

public class BIFDbManager : DbManager
{
    public BIFDbManager() : base("Connection string name") { }

    public Table<DirectoryListing> DirectoryListings { get { return GetTable<DirectoryListing>(); } }
}

Answer 3

Как долго вы можете работать без базы данных?Если это проблема, представьте ее поздно.И да, это, вероятно, означает, что вы добавляете слой.