How can the below code can be refactored with design pattern?

I would look at replacing the BLL code with the following. With the main focus being replacing the Convert.ToInt16 repetition with a method. The other area of concern is the inability to mock your BAL code. To overcome this I have written a quick and dirty interface which allows better unit testing.

namespace BAL
{
    // interfaces allow the class ot be easily mocked
    internal interface ICustomDataColumnTryParse
    {
        bool TryParseBool(string columnName);
    }

    // interfaces allow the class ot be easily mocked
    internal interface INotificationSettingsDomain
    {
        DataTable GetNotificationList();
    }

    // sample implementation of the interface
    internal class NotificationSettingsBAL : INotificationSettingsDomain
    {
        public DataTable GetNotificationList()
        {
            // do whatever you need to return information from your data repository
            throw new System.NotImplementedException();
        }
    }

    internal class NotificationSettings : ICustomDataColumnTryParse
    {
        // properties are more widely accepted for consumers of this class over
        // traditional fields / variables, but it really depends on 'what' you want
        // to use these values for?
        internal bool SignUPFBPost { get; private set; }
        internal bool SignUPEmails { get; private set; }
        internal bool SignUPPushNotification { get; private set; }
        internal bool SignUPFCActivity { get; private set; }
        internal bool SignUPBubbleNotification { get; private set; }
        internal bool SignUPGlobeNotification { get; private set; }

        private DataTable m_notificationListDataTable;

        internal NotificationSettings()
            : this(new NotificationSettingsBAL())
        { }

        // using an interface allows mocking of the 'NotificationSettingsBAL' object
        public NotificationSettings(INotificationSettingsDomain notificationSettingsDomain)
        {
            // prefer suffixes over prefixes for naming conventions
            m_notificationListDataTable = notificationSettingsDomain.GetNotificationList();

            SignUPFBPost = TryParseBool("FBWallPost");
            SignUPEmails = TryParseBool("Emails");
            SignUPPushNotification = TryParseBool("PushNotification");
            SignUPFCActivity = TryParseBool("FCActivity");
            SignUPBubbleNotification = TryParseBool("BubbleNotification");
            SignUPGlobeNotification = TryParseBool("GlobNotification");
        }

        // this can be a method on this class, extension method (my preference) or a static method
        // i have opted for an internal class method coded against an interface so the data table 
        // isn't passed around. 
        public bool TryParseBool(string columnName)
        {
            // this can allow for additional logic if we wanted to get a different row index
            var row = m_notificationListDataTable.Rows[0];
            var value = row[columnName];

            if (value == null)
            {
                return false;
            }

            int valueAsInt = 0;
            int.TryParse(value.ToString(), out valueAsInt);
            return valueAsInt == 1;
        }
    }
}

As for replacing the switch statement you might be over-using an architectural pattern. I would only choose something like a strategy pattern if the business logic is likely to change or that additional switch statements will be added / removed with a high frequency in the future.

I would start with those steps:

• Create an enum for your flags 'FBWallPost', 'Emails', and so on.
• Put yor "signs" into an boolean array indexed by values of that enum (instead of individual booleans), then you can easily create a loop around that.

After that replacement I would check how much of the second part of your code can be refactored to general methods. Then I would look at the remaining parts and how much code duplication is still in there. Eventually I would try to apply strategy pattern, having classes FBWallPostStrategy, EmailsStrategy etc. with a common base class. Those classes may later replace the enum I have introduced first (you won't need it then anymore), keep only the individual code parts that are special for the particular case. The common code goes either to the common base class or a separate class applying "template method" pattern.