برای این سیستم فرضی چه تحلیلی دارید؟

[amirjalili]

سلام..
فرض کنید نرم افزاری دارید که قرار است معماری 3 لایه داشته باشد.
این نرم افزار ممکنه در آینده بخواد دیتابیس خودش رو عوض کنه و مثلا از sql بره روی oracle .
حالا باید چه کاری انجام بدیم که مجبور نباشیم لایه Data Access رو در این تغییرات دیتابیس عوض کنیم و مجبور نباشیم دوباره کد بزنیم؟
لایه Data Access و Business logic رو چگونه باید طراحی کنیم و از interface ها چطور در راستای رسیدن به این هدف میتونیم بهره ببریم.

فرض کنید نمیخواهیم از ORM ها استفاده کنیم.

[amirjalili]

دوستان فکر یا ایده ای ندارید؟ پیشنهاد چطور ؟

[amirjalili]

سلام..
بعد از 95 بار بازدید و عدم وجود جواب نهایتا خودم جواب رو میگم :
راه حل استفاده از Factory pattern هست که باعث میشه کسی که میخواد با توجه به subclass ها شیئی رو بسازه وابسته به کلاس های فرزند نباشه و مجبور نباشه دونه دونه همه فرزند ها رو نمونه گیری کنه و مشکلات دیگه :
کد :

using System;
using System.Collections.Generic;
using System.Text;

namespace Design_Pattern_Learning
{


public enum DataBase
{
SQLServer_SelectAllFromX,
Oracle_SELECTX
}
public interface IDatabase
{
DataBase GetCommand();
}

static class Factory
{
public static IDatabase doFactory(DataBase DBName)
{
switch (DBName)
{
case DataBase.SQLServer_SelectAllFromX:
return new Oracle();
case DataBase.Oracle_SELECTX:
return new SQLServer();
default :
return new Oracle();
}
}
}

class Oracle:IDatabase
{
public DataBase GetCommand()
{
return DataBase.Oracle_SELECTX;
}
}

class SQLServer : IDatabase
{
public DataBase GetCommand()
{
return DataBase.SQLServer_SelectAllFromX;
}
}

}
class Program
{
static void Main(string[] args)
{
Console.WriteLine(Factory.doFactory(DataBase.Oracl e_SELECTX).GetCommand().ToString());
Console.WriteLine(Factory.doFactory(DataBase.SQLSe rver_SelectAllFromX).GetCommand().ToString());
Console.ReadLine();
}
}