Уровень бизнес-логики

Question

Я программирую приложения, управляемые данными, используя asp.net с элементами управления telerik (v2009 q2). У меня есть класс с именем BLL, который содержит (почти только) статические классы, которые возвращают разные объекты, принимая некоторый идентификатор в качестве параметра. Обычно возвращаемая группа объектов в виде списков.

Мой вопрос заключается в том, есть ли в этом какие-либо недостатки в архитектуре, всегда с использованием статики. Я знаю, что люди делают свои Busines Layer и DataAccess как разные проекты. В чем преимущество того, что это проект? Так что я могу добавить больше функциональности или просто так аккуратнее.

Заранее спасибо

Answer 1

Использование статических методов в качестве метода ввода не представляет особой проблемы. Это действительно зависит от того, есть ли у вас области работы, где вам нужно хранить состояние, так как статические определения могут не позволить вам хранить или отделять информацию о состоянии. К счастью, возврат от использования статических объявлений к декларациям членов обычно менее болезнен, чем обратный. Вы можете даже не столкнуться с этим как с проблемой, если элементы, возвращаемые такими методами, несут полную ответственность за состояние.

Отдельные библиотеки / проекты полезны для разбиения единиц работы. Нет строгих требований о том, что все должно быть разделено на разные библиотеки, хотя вы можете увидеть причуды со статическими переменными-членами, особенно в многопоточных приложениях, как упомянул Дэйв Сверски.

Наличие отдельных библиотек также дает следующие преимущества:

1. Лучшее разделение изменений во время разработки, поскольку границы проекта обычно совпадают с границами контроля исходного кода, что позволяет большему количеству людей работать одновременно по всей поверхности вашей платформы.
2. Отдельные детали, которые могут обновляться независимо в производстве, при условии совместимости компоновки и интерфейсов.
3. Лучшая организация того, какие виды поведения, функции и роли пересекаются для данного сегмента на каждом уровне, будь то BLL или DAL. Некоторые разработчики предпочитают строго изолировать компоненты на основе того, что пользователям разрешено работать с элементами, предоставленными в данном BLL.

Однако некоторые партии обнаружили, что большие монолитные библиотеки работают лучше для них. Вот некоторые преимущества, которые важны в этом сценарии.

1. Более быстрое время компиляции для проектов, в которых старые компоненты и зависимости редко изменяются (особенно важно для разработчиков C / C ++!). Все исходные файлы, которые не изменяются, могут подсказывать компилятору и избегать перекомпиляции целых проектов.
2. Обновления и управление одним файлом (или с небольшим количеством файлов) для проектов, в которых важно минимизировать количество объектов, присутствующих в данном месте. Это очень желательно для людей, которые предоставляют библиотеки для потребления другими сторонами, так как они менее восприимчивы к тому, что отдельные элементы публикуются или обновляются не по порядку.
3. Автоматическая компоновка пространства имен в проектах Visual Studio .NET, где использование подпапок автоматически подразумевает начальное пространство имен, которое будет присутствовать при добавлении нового кода. Не очень хороший перк, но некоторые люди находят это полезным.
4. Разделение групп BLL и DAL по абстракции базы данных или сервера. Это несколько средний уровень, но как уровень организации люди считают этот уровень более удобным для долгосрочного развития. Это позволяет людям идентифицировать вещи по месту их хранения или получения. Но в качестве компромисса отдельные проекты могут быть более сложными, хотя и управляемыми через # 3.

Наконец, я заметил одну вещь: похоже, вы реализовали вложенные статические классы. Если другие люди, использующие вашу работу, находятся в среде с недоступными intellisense или другими ярлыками, они могут посчитать эту настройку очень сложной для использования. Вы можете рассмотреть возможность развертывания некоторых уровней вложенности в отдельные (или вложенные) пространства имен. Это также полезно для уменьшения количества печатания, необходимого для объявления объектов интереса, поскольку объявления пространства имен должны присутствовать только один раз, когда статические вложенные элементы должны присутствовать каждый раз. Вашим коллегам это понравится.

Answer 2

Наличие BLL и DAL в отдельных проектах (т. Е. В отдельных сборках) означает, что их можно использовать с различными пользовательскими интерфейсами без повторной компиляции, но, что более важно, граничные интерфейсы и зависимости библиотек DLL относительно четко определены (хотя это не гарантирует отличный дизайн, по крайней мере, обеспечивает разделение). Все еще возможно иметь одну сборку с большим логическим разделением, поэтому это не требуется и не достаточно.

Что касается статических методов и классов бизнес-объектов, это может быть необычно и иметь недостатки, но это не влияет на то, разделены ли ваши слои или нет.

Answer 3

namespace BLL
{
    public class tblCity
    {
        public tblCity()
        {
            //
            // TODO: Add constructor logic here
            //
        }
        private int iCityId;
        private string sCityName;

        public int CityId
        {
            get
            { return iCityId; }
            set
            { iCityId = value; }
        }
        public string CityName
        {
            get
            {
                return sCityName;
            }
            set
            { sCityName = value; }

        }
        public int InserttblCity()
        {
            DBAccess db = new DBAccess();
            //db.AddParameter("@iSid", iSid);
            db.AddParameter("@sCityName", sCityName);

            return db.ExecuteNonQuery("tblCity_Insert", true);
        }
        public DataSet SelectAlltblCity()
        {
            DBAccess db = new DBAccess();
            return db.ExecuteDataSet("tblCity_SelectAll");
        }
        public DataSet CheckCityName()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@sCityName", sCityName);
            return db.ExecuteDataSet("tblCity_CheckCity");
        }
        public DataSet SelectDistinctCityWithId()
        {
            DBAccess db = new DBAccess();
            //db.AddParameter("@iCityName", iCityName);
            return db.ExecuteDataSet("tblCity_getLastId");
        }
        public int UpdatetblCity()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@iCityId", iCityId);
            db.AddParameter("@sCityName", sCityName);
            return db.ExecuteNonQuery("[tblCity_Update]", true);
        }
        public int DeletetbltblCity()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@iCityId", iCityId);

            return db.ExecuteNonQuery("[tblCity_Delete]", true);
        }
        public DataSet FindPropertyLocationSubCategory()
        {
            DBAccess db = new DBAccess();
            db.AddParameter("@iCityId", iCityId);
            return db.ExecuteDataSet("tblPropertyDetails_FindPropertyLocationSubCategory");
        }
        public DataSet SelectDistinctPLCNAmeWithId()
        {
            DBAccess db = new DBAccess();

            return db.ExecuteDataSet("tblCity_getLastId");
        }

    }
}

Answer 4

Мой вопрос: есть ли архитектурные недостатки к этому, всегда используя статический.

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

Я знаю, что люди делают свой бизнес слой и уровень DataAccess как разные проекты. В чем его преимущество быть проектом? Так что я могу добавить больше функциональность или просто аккуратнее таким образом.

Преимущества:

1. Работать с несколькими разработчиками проще (в зависимости от среды и системы контроля версий)
2. Принудительное отделение уровней логики / защиты от остальной части вашего решения
3. Легче группировать и управлять, если ваш BLL становится большим

Answer 5

Одним из преимуществ отдельного проекта является то, что если вам нужно обновить приложение, но изменить только BLL, вы можете внести изменения, перекомпилировать DLL и поместить ее в папку bin, где приложение развернуто в IIS, без необходимости повторно развернуть все веб-приложение

Answer 6

Если ваше приложение не имеет состояния, полностью статические методы / классы не должны быть проблемой. Однако, если ваше приложение является многопоточным, а BLL выполняет чтение и фиксацию, вы можете столкнуться с проблемами безопасности потоков.