مقایسه ساختار سیمفونی با سایر فریمورکها

[bestirani2]

سلام دوستان
از اونجایی که برای سیمفونی بخش جدا وجود نداره این تاپیک رو اینجاد کردم تا اگه کسی سوالی راجب این فریم ورک داره اینجا بپرسه تا بقیه دوستان جواب بدند.

در مورد معرفی سیمفونی هم بگم که یه فریم ورک قوی و مطرح پی اچ پی است که یادگیریش نسبت به فریم ورک های دیگه سخت تر هست ولی به شدت مهندسی و قدرتمند است. در مورد انعطاف پذیری سیمفونی هم اینطوری بگم که همه چیز داخل سیمفونی یه باندل در نظر گرفته میشه از خود فریم ورک و قسمت های مختلفش تا پروژه ای که شما دارید مینویسید و این یعنی نهایت انعطاف و قابلیت سفارشی کردن. به عنوان نمونه هم فریم ورک Laravel که اومده فریم ورک سیمفونی رو توسعه داده.
مزیت دیگر سیمفونی، پشتیبانی قوی اش هست. توسعه سیمفونی با شرکت sensiolabs است که از دیگر محصولات این شرکت میشه به Twig و Doctrine اشاره کرد که هم در سیمفونی و هم دیگر فریم ورک ها استفاده میشه. همچنین آپدیت سیمفونی به صورت منظم انجام میشه و هر شش ماه یکبار یه نسخه جدید پابلیش میشه.

از نظر پرفورمنس هم قابل قبول هست و با تنظیمات مناسب سرعتش از فریم ورکی مثل YII بالاتر میره.

در مورد برنامه های مطرح که از کل سیمفونی یا قسمت هایی از اون استفاده شده میتونم اینها رو نام ببرم
لاراول، composer، مدیریت محتوای انجمن phpBB، دروپال، Delecious، Yahoo! Bookmark، Yahoo! Answers، Exercise.com، Dailymotion.com و ...

[bestirani2]

واسه اینکه تاپیک فعال بشه یک سری از دستورات سیمفونی و معادلش رو در YII قرار میدم. کسی معادلش در بقیه فریم ورک ها رو میدونه بگه.


دسترسی به یک اکشن فقط توسط نقش مدیریت



public function filters()
{
return array(
'accessControl', // perform access control for CRUD operations
)
}


public function accessRules()
{
return array(
array('allow',
'actions'=>array('hello'),
'roles'=>array('ROLE_ADMIN'),
),

);
}
}


public function actionHello($name)
{
// ...
}



معادلش در سیمفونی



/**
* @Security("has_role('ROLE_ADMIN')")
*/
public function helloAction($name)
{
// ...
}



اکشن لاگین



public function actionLogin()
{
if (!defined('CRYPT_BLOWFISH')||!CRYPT_BLOWFISH)
throw new CHttpException(500,"This application requires that CSHARP was compiled with Blow fish support for crypt().");


$model=new LoginForm;


// if it is ajax validation request
if(isset($_POST['ajax']) && $_POST['ajax']==='login-form')
{
echo CActiveForm::validate($model);
Yii::app()->end();
}


// collect user input data
if(isset($_POST['LoginForm']))
{
$model->attributes=$_POST['LoginForm'];
// validate user input and redirect to the previous page if valid
if($model->validate() && $model->login())
$this->redirect(Yii::app()->user->returnUrl);
}
// display the login form
$this->render('login',array('model'=>$model));
}



معادل سیمفونی همراه با مسیریابی



/**
* @Route("/login", name="_demo_login")
* @Template()
*/
public function loginAction(Request $request)
{
if ($request->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) {
$error = $request->attributes->get(SecurityContext::AUTHENTICATION_ERROR);
} else {
$error = $request->getSession()->get(SecurityContext::AUTHENTICATION_ERROR);
}


return array(
'last_username' => $request->getSession()->get(SecurityContext::LAST_USERNAME),
'error' => $error,
);
}


/**
* @Route("/login_check", name="_security_check")
*/
public function securityCheckAction()
{
// The security layer will intercept this request
}



لود کردن اطلاعات یه مدل بر اساس آی دی در YII



public function actionShow($id)
{


/** @var $model Posts $model */
$model=Posts::model()->findByPk($id);
if($model===null)
throw new CHttpException(404,'The requested page does not exist.');




if(isset($_POST['Posts']))
{
$model->attributes=$_POST['Posts'];


}


}



معادل آن در سیمفونی



/**
* @ParamConverter("post", class="SensioBlogBundle:Post")
*/
public function showAction(Post $post)
{
}

[MMSHFE]

Yii هم قسمت فیلترها و معماری پلاگینهای خودش رو از سیمفونی گرفته. درخواست ایجاد بخش اختصاصی فریمورک سیمفونی رو برای مدیران سایت برنامه نویس فرستادم. راستی بد نیست برای اینکه تاپیک از حالت اختصاصی در بیاد، شما بیشتر توی ساختار سیمفونی متمرکز بشین و کاربران حرفه ای هر فریمورک معادل همون فریمورک رو معرفی کنن.

[MMSHFE]

برای مثال، در بحث تعیین سطح دسترسیها، درسته که در Yii برای یک متد ممکنه بنظر بیاد استفاده از دو متد دیگه برای تعیین سطح دسترسی کار اضافه بشه ولی در تعداد بالای متدها، بهینه تره. مثال:
در Yii :


public function filters() {
return array(
'accessControl',
);
}


public function accessRules() {
return array(
array('allow',
'actions'=>array('hello', 'edit', 'manage', 'test'),
'roles'=>array('ROLE_ADMIN'),
),
array('deny',
'users'=>array('*'),
),
);
}

public function actionHello() { ... }

public function actionEdit() { ... }

public function actionHello() { ... }

public function actionTest() { ... }

در سیمفونی :


/**
* @Security("has_role('ROLE_ADMIN')")
*/
public function helloAction() { ... }

/**
* @Security("has_role('ROLE_ADMIN')")
*/
public function editAction() { ... }

/**
* @Security("has_role('ROLE_ADMIN')")
*/
public function manageAction() { ... }

/**
* @Security("has_role('ROLE_ADMIN')")
*/
public function testAction() { ... }

منظورم اینه که توی Yii کلاً سطوح دسترسی یکجا تعریف میشه و پیدا کردن و مدیریتش هم نسبتاً راحتتره (وقتی به ساختارش عادت کنیم) درحالی که توی سیمفونی سطح دسترسی هر متد باید با ساختار مشابه PHPDoc قبل از همون متد مشخص بشه و از اونجا که توی ساختار PHPDoc دستوراتی مثل @Security نداریم، موقع تولید خودکار Documentation با کمک PHPDoc با پیغامهای خطا مواجه میشیم. البته مطمئن نیستم که سیمفونی این قابلیت (تعیین سطوح دسترسی یکجا) رو مثل Yii نداشته باشه.

[bestirani2]

Yii هم قسمت فیلترها و معماری پلاگینهای خودش رو از سیمفونی گرفته. درخواست ایجاد بخش اختصاصی فریمورک سیمفونی رو برای مدیران سایت برنامه نویس فرستادم. راستی بد نیست برای اینکه تاپیک از حالت اختصاصی در بیاد، شما بیشتر توی ساختار سیمفونی متمرکز بشین و کاربران حرفه ای هر فریمورک معادل همون فریمورک رو معرفی کنن.

در مثال هایی که زدم در بالا، قصدم معرفی قدرت annotation در سیمفونی بود و روی ساختار فیلتر و ... تمرکز نکرد.
منظورتون از پلاگین اگه همون ماژول هست، با سیستم باندل سیمفونی کامل فرق داره البته در Yii 2 روال کار عوض شده و از Composer هم پشتیبانی میشه.
بنده فقط معادل Yii رو نوشتم چون YII رو بیشتر از سیمفونی کار نکرده باشم، کمترم کار نکردم.
اگه بخواید میتونم براتون چند نمونه کار Yii ام هم بفرستم.

[MMSHFE]

درمورد لاگین هم توی Yii عدم وجود BLOWFISH رو چک کردین ولی در لاراول انجام ندادین و این مسئله باعث شده کد Yii طولانیتر بنظر برسه. ازطرفی توی Yii کد بررسی صحت اطلاعات لاگین با AJAX رو هم گذاشتین که در کد سیمفونی باز نیست و باعث شده کد سیمفونی کوتاهتر بنظر بیاد. یا فرضاً توی کد Yii همه کامنتها رو هم میگذارین و توی کد سیمفونی خیر و درنتیجه باز کدهای Yii طولانی بنظر میاد و فکر میکنم این جور مقایسه کردن، منصفانه نباشه. یک نمونه از کوتاهترین کدهایی که میشه برای لاگین توی Yii نوشت اینطوریه:

public function actionLogin() {
$model = new LoginForm();
if(isset($_POST ['LoginForm'])) {
$model->attributes = $_POST ['LoginForm'];
if($model->validate() && $model->login()) {
$this->redirect(Yii::app()->user->returnUrl);
}
else {
Yii::app()->user->setFlash('failure', 'خطا در نام کاربری یا رمز عبور');
}
}
$this->render('login', array ('model' => $model));
}
معادل سیمفونی اون با شما

[MMSHFE]

درمورد لاگین هم توی Yii عدم وجود BLOWFISH رو چک کردین ولی در لاراول انجام ندادین و این مسئله باعث شده کد Yii طولانیتر بنظر برسه. ازطرفی توی Yii کد بررسی صحت اطلاعات لاگین با AJAX رو هم گذاشتین که در کد سیمفونی باز نیست و باعث شده کد سیمفونی کوتاهتر بنظر بیاد. یا فرضاً توی کد Yii همه کامنتها رو هم میگذارین و توی کد سیمفونی خیر و درنتیجه باز کدهای Yii طولانی بنظر میاد و فکر میکنم این جور مقایسه کردن، منصفانه نباشه. یک نمونه از کوتاهترین کدهایی که میشه برای لاگین توی Yii نوشت اینطوریه:

public function actionLogin() {
$model = new LoginForm();
if(isset($_POST ['LoginForm'])) {
$model->attributes = $_POST ['LoginForm'];
if($model->validate() && $model->login()) {
$this->redirect(Yii::app()->user->returnUrl);
}
else {
Yii::app()->user->setFlash('failure', 'خطا در نام کاربری یا رمز عبور');
}
}
$this->render('login', array ('model' => $model));
}
معادل سیمفونی اون با شما

[bestirani2]

منظورم اینه که توی Yii کلاً سطوح دسترسی یکجا تعریف میشه و پیدا کردن و مدیریتش هم نسبتاً راحتتره (وقتی به ساختارش عادت کنیم) درحالی که توی سیمفونی سطح دسترسی هر متد باید با ساختار مشابه PHPDoc قبل از همون متد مشخص بشه و از اونجا که توی ساختار PHPDoc دستوراتی مثل @Security نداریم، موقع تولید خودکار Documentation با کمک PHPDoc با پیغامهای خطا مواجه میشیم. البته مطمئن نیستم که سیمفونی این قابلیت (تعیین سطوح دسترسی یکجا) رو مثل Yii نداشته باشه.

داخل سیمفونی هم میشه به صورت یکجا در فایل کانفیگ تنظیم کرد. هر چیزی حتی مسیریابی رو میشه به صورت جدا هم تعریف کرد. جدا تعریف کردن توی پروژه های بزرگ یا نوشتن برنامه third-part خودش رو بیشتر نشون میده. در کل سیمفونی برای هر چیزی چندین راه قرار داده ولی راه پیشنهادیش همینی هست که بنده قرار دادم. در مورد PHPDoc هم هیچ مشکلی نیست و به راحتی کد رو تولید میکنیم. اگه IDE ای که استفاده میکنید ساپورت خوبی داشته باشه رنگ annotation هار رو عوض میکنه که به راحتی از بقیه موارد قابل تشخیص باشه.

در مورد معادل کد بالا هم توی سیمفونی میشه



/**
* @Security("has_role('ROLE_ADMIN')")
*/
class WelcomeController extends Controller
{


public function helloAction() { ... }

public function editAction() { ... }

public function manageAction() { ... }

public function testAction() { ... }


و نیاز نیست برای هر اکشن جدا تعریف کنید

[MMSHFE]

درمورد مثال سوم هم (Load خودکار مدل) کوتاهترین کد Yii که میشه نوشت تا معادل کد سیمفونی شما باشه، اینه:

public function actionShow($id) {
$model = $this->loadModel($id);
...
}

[bestirani2]

درمورد لاگین هم توی Yii عدم وجود BLOWFISH رو چک کردین ولی در لاراول انجام ندادین و این مسئله باعث شده کد Yii طولانیتر بنظر برسه. ازطرفی توی Yii کد بررسی صحت اطلاعات لاگین با AJAX رو هم گذاشتین که در کد سیمفونی باز نیست و باعث شده کد سیمفونی کوتاهتر بنظر بیاد. یا فرضاً توی کد Yii همه کامنتها رو هم میگذارین و توی کد سیمفونی خیر و درنتیجه باز کدهای Yii طولانی بنظر میاد و فکر میکنم این جور مقایسه کردن، منصفانه نباشه. یک نمونه از کوتاهترین کدهایی که میشه برای لاگین توی Yii نوشت اینطوریه:
معادل سیمفونی اون با شما

در مورد BLOWFISH و ... چون من مثال پیشفرض هر دو فریم ورک رو کپی کردم قرار دادم از طرفی خود سیمفونی این مورد و ... رو انجام میده

شما تنها کافیه هر فرم لاگینی رو که میخواید بفرستید به اکشنی که اسمش رو گذاشتید _security_check بقیه کارهاش دیگه با سیمفونی هست حتی میتونید این اکشن رو در کل تعریف نکنید. اینجا صرف واسه مسیریابی تعریف شده. به بیان دیگر خود سیمفونی مواری مثل لاگین و لاگ اوت رو به صورت پیش فرض قرار داده و نیازی نیست شما کدی بنویسید.

[MMSHFE]

در مورد PHPDoc هم هیچ مشکلی نیست و به راحتی کد رو تولید میکنیم. اگه IDE ای که استفاده میکنید ساپورت خوبی داشته باشه رنگ annotation هار رو عوض میکنه که به راحتی از بقیه موارد قابل تشخیص باشه.
بحث داخل IDE نیست. دقت کنید گفتم تولید مستندات با PHPDoc نه راهنماهای IDE و منظورم تولید داکیومنت HTML و گراف ارتباط بین کلاسها و... با ابزار PHPDoc توی لینوکس و... است که وجود این دستورات غیرمجاز (Security@) باعث میشه نتونه درست کار کنه و خطا بده.

در مورد معادل کد بالا هم توی سیمفونی میشه...
و نیاز نیست برای هر اکشن جدا تعریف کنید
نه دیگه نشد، ببینید الآن شما اومدین این متدها رو توی کلاس جداگانه گذاشتین و اگه قرار به این کار باشه توی Yii هم میشه کلاً سطح دسترسی متدهای یک کنترلر خاص رو توی کنترلر والد (components/Controller) تعریف کرد. تقاضا میکنم مثل حالت معمول Yii شما هم همه متدهای یک کنترلر رو توی یک کلاس بگذارین کنار بقیه متدها و سطح دسترسیهای هرکدوم رو مشخص کنید.

[MMSHFE]

در مثال هایی که زدم در بالا، قصدم معرفی قدرت annotation در سیمفونی بود و روی ساختار فیلتر و ... تمرکز نکرد.
منظورتون از پلاگین اگه همون ماژول هست، با سیستم باندل سیمفونی کامل فرق داره البته در Yii 2 روال کار عوض شده و از Composer هم پشتیبانی میشه.
بنده فقط معادل Yii رو نوشتم چون YII رو بیشتر از سیمفونی کار نکرده باشم، کمترم کار نکردم.
اگه بخواید میتونم براتون چند نمونه کار Yii ام هم بفرستم.
نه نیازی نیست و به اندازه کافی درمورد شما توی مدت حضورتون در برنامه نویس و بررسی پستهاتون، شناخت پیدا کردم و صرفاً از این جهت گفتم که کسی که متمرکز روی یک فریمورک کار میکنه قطعاً راههای مختلف رسیدن به مقصد رو بیشتر پیگیری میکنه و بهینه ترین راهها رو هم راحتتر و سریعتر پیدا میکنه. درمورد پلاگینها هم نه منظورم Extensionهای Yii بود. بهرحال توی Yii 2 همونطور که اشاره کردین Composer هم پشتیبانی شده و ازطرفی Yii میتونه به راحتی افزونه های سیمفونی و زند و کلاً هر فریمورکی که از Composer پشتیبانی کنه رو به خودش اضافه کنه و به کار بگیره (بدون حتی یک خط تغییر در کد اون افزونه) که قطعاً مستحضر هستید و این قابلیت از نسخه 1.1 بوده و مختص نسخه 2 نیست.

[bestirani2]

درمورد مثال سوم هم (Load خودکار مدل) کوتاهترین کد Yii که میشه نوشت تا معادل کد سیمفونی شما باشه، اینه:

public function actionShow($id) {
$model = $this->loadModel($id);
...
}
در اینجا شما از یه متد به اسم loadModel استفاده کردید که منطق پیدا کرن آی دی رو سپردید به اون چون برای اکشن های حذف و مشاهده هم نیاز دارید. این بر میگرده به قابلیت خود پی اچ پی که منطقی هم هست. من بحثم سر نحوه عملکرد هست + شما تا فقط مقدار رو از دیتابیس دارید. حالا اگه از ویو مقدار های جدید پست بشه چی ؟ که باید ادامش رو نوشت. من بحثم کلاً سر کوتاهی و طولانی بودن کد نیست بحثم سرم مهندسی هست.
در سیمفونی شما از model binding استفاده کردید ولی در YII این کار رو باید دستی انجام بدید. از model binding برای موارد دیگه هم میشه استفاده کرد مثل Request و ... + اینکه میتونید Model Binding اختصاصی خودتون رو بنویسید.

در کنار این موارد annotation ها رو داریم که کد رو خوانا تر و قابل فهمتر میکنه و خیلی از موارد رو میشه به راحتی انجام داد که باز هم میشه annotation اختصاصی خودتون هم بنویسید که این مورد در ساخت مدل خیلی خودش رو نشون میده.

از طرف دیگه برای تنظیم برنامه یکی از گزینه ها Yaml هست که بازم برنامه خواناتر میشه

در کل هدف سیمفونی خوانایی بیشتر، قابلیت استفاده بیشتر و ... هست

از طرف دیگه شما میتونید یه باندل بنویسید که روی قسمت های دیگه سیتم تاثیر بگذاره. (منظورم این نیست یه کلاس رو extend کنید.) که در کنار امکان ارث بری باندل ها از هم واقعا قدرتمند میشه.

[MMSHFE]

خوب این مسئله (اجرای خودکار یک کد قبل از اکشنها برای انجام کارهایی مثل Automatic Model Binding و...) توی کنترلرهای Yii هم با متد init درنظر گرفته شده. برای مثال کافیه این متد رو به کنترلرتون اضافه کنید:

public function init() {
if(isset($_GET['id'])) {
$this->model = $this->loadModel($_GET['id']);
}
}
و اونوقت توی هر متدی که پارامتر id$ داشته باشه میتونید با this->model$ به مدل متناظر با id$ دسترسی پیدا کنید.

[bestirani2]

نه نیازی نیست و به اندازه کافی درمورد شما توی مدت حضورتون در برنامه نویس و بررسی پستهاتون، شناخت پیدا کردم و صرفاً از این جهت گفتم که کسی که متمرکز روی یک فریمورک کار میکنه قطعاً راههای مختلف رسیدن به مقصد رو بیشتر پیگیری میکنه و بهینه ترین راهها رو هم راحتتر و سریعتر پیدا میکنه. درمورد پلاگینها هم نه منظورم Extensionهای Yii بود. بهرحال توی Yii 2 همونطور که اشاره کردین Composer هم پشتیبانی شده و ازطرفی Yii میتونه به راحتی افزونه های سیمفونی و زند و کلاً هر فریمورکی که از Composer پشتیبانی کنه رو به خودش اضافه کنه و به کار بگیره (بدون حتی یک خط تغییر در کد اون افزونه) که قطعاً مستحضر هستید و این قابلیت از نسخه 1.1 بوده و مختص نسخه 2 نیست.
درسته کاملاً. البته من بیشتر با Yii کار کردم تا سیمفونی چون نظر شخصی من اینه سیمفونی برای کارهای متوسط و کوچیک زیادی گنده هست. مثل این میمونه یه هوایپما رو بیارید توی جاده تا باهاش برید شمال.

[bestirani2]

خوب این مسئله (اجرای خودکار یک کد قبل از اکشنها برای انجام کارهایی مثل Automatic Model Binding و...) توی کنترلرهای Yii هم با متد init درنظر گرفته شده. برای مثال کافیه این متد رو به کنترلرتون اضافه کنید:

و اونوقت توی هر متدی که پارامتر id$ داشته باشه میتونید با this->model$ به مدل متناظر با id$ دسترسی پیدا کنید.

من منظورم اینجا استاندارد های تایید شده جدید هست مگرنه هر چیزی رو میشه به نحوی انجام داد. حالا فرض کنیم فقط یه کنترلمون ای دی نیاز داره یکی دیگه اسم یه چیز دیگست و ...
از طرفی حتی میشد به جای init() از سازنده خود پی اچ پی استفاده کرد ولی باز استفاده از init شیوه قشنگ تری داره (همینطور که میدونید خود init هم توی سازنده صدا زده میشه)
در کل منظور اینه به هر حال هر کاری رو میشه به طریقی کوتاهتر انجام داد ولی مهم خوانایی ، استفاده مجدد، نگهداری و ... هست که توی پروژه های بزرگ و گروهی نیاز هست مگرنه بنده سرعت توسعه ام با YII خیلی بیشتر از سیمفونی هست به خصوص که برای هر چیزی یه فیلتر یا Behavier و ... دارم که خیلی کد نویسی رو برام سریع کرده. حتی بیشتر از قسمت های فریم ورک رو بنا به نیاز خودم و افزاش سرعت پروژه Ovveride کردم. خیلی هم سریع پروژم رو با YII میبندم ولی مسئله اینجاست اگه یه پروژه بزرگ و گروهی باشه اینجاست که مشکل واقعی ایجاد میشه مگرنه YII به نظر من توی سرعت توسعه، پرفورمنس و وب 2 عالیه. سیمفونی همه چیز رو به حد نرمال داره ولی از نظر ساپورت و مهندسی بودن + ابتکارات حرف اول رو میزنه. من خیالم راحت هست سر تایم مشخص آپدیت میاد. الان شما میتونید برید توی سیمفونی و بگید فلان نسخه سیمفونی توی چه تاریخی میاد و جوابش رو ببینید. همیشه جدیدترین ویژیگی های زبان PHP و دیگر اصول جدید مهندسی نرم افزار رو داخل نسخه های جدیدش جا میده. برای هر کاری چندین راه رو پیش رو گذاشته. خوانایی کدش بالاست که این برای کار گروهی و پروژه های بزرگ خیلی مهمه.

[bestirani2]

خوب این مسئله (اجرای خودکار یک کد قبل از اکشنها برای انجام کارهایی مثل Automatic Model Binding و...) توی کنترلرهای Yii هم با متد init درنظر گرفته شده.


البته این چیزی که شما گفتید معنی مدل بایندینگ رو نمیده
مدل بایندینگ یعنی یه مدل رو به عنوان یه آرگومان بدید و اون خودش خودکار اون رو ایجاد، مقدار دهی و ... رو انجام بده علاوه بر اینکه این مسئله که شما گفتید مدل بایندینگ حساب نمیشه فرض کنید 5 تا کنترل دارید که هر کدمشون یه مدل رو صدا میکنند. شما میخواید هر 5 تاش رو اون بالا قرار بدید؟ خوب بیاریدش توی خود اکشن، خوانایی کد هم بیشتر میشه. بایندینگ کردن هم فقط محدود به مدل نمیشه. مثلاً میتونید ابجکت های دیگه هم بگیرید به این روش مثل تاریخ، request و ...

این الان اصول جدیدی هست که همه جا رعایت میشه. شاید بگید به جای اینکه request رو داخل ارگومان بگیرم از داخل کنترل میگیرم. خوب اینم درسته ولی کدوم زیباتر هست؟

در نسخه قبل 2.2.4 سیمفونی باید همینطوری Request رو میگرفتی با $this->getReques() ولی لان این روش رو منسوخ کرده سیمفونی و به جاش یه متعیر از نوع Request رو دریافت میکنیم.

[MMSHFE]

درسته و اینها همه قابلیتهای خوبی هست که سیمفونی داره ولی بطور کلی راه حل زیاده. ساخت annotaion اختصاصی تا وقتی خوبه که استانداردها رو بهم نزنه. مثلاً وقتی توی استاندارد PHPDoc مورد Security@ نداریم، هیچ کدی نباید به این استاندارد دست بزنه و خرابش کنه چون درسته که مزیتهایی برای کاربران داره ولی فرضاً یکسری قابلیتهای دیگه رو که بر اساس اون استاندارد بنا شدن، خراب میکنه و از کار میندازه.
بهرحال اون موردی که گفتین (یک اکشن به id احتیاج داشته باشه و یکی دیگه به یک مقدار دیگه)، میتونیم اینطوری توی Yii پوشش بدیم:


class UserController extends Controller {
public function init() {
foreach($_GET as $key => $value) {
$this->${'m_' . $key} = User::model()->findByAttributes(array($key=>$value));
}
}
public function actionView($id) {
$this->renderText('<pre>' . print_r($this->m_id->attributes, true) . '</pre>');
}
public function actionSayHello($name) {
$this->renderText('<p>Hello ' . $this->m_name->name . ' ' . $this->m_name->family . '</p>');
}
}

درسته که راهی که Symfony ارائه کرده ساده تره ولی قبول کنید برای کسی که برنامه نویسه، این راه هم کار خاصی نیست و پیچیدگی نداره و ازطرفی هم استانداردها رو بهم نمیزنه. ازطرف دیگه، توی Yii 2 با قابلیت متد runAction میشه دقیقاً پارامترها رو اصلاح کرد. برای مثال:

public function runAction($id, $params = array()) {
parent::runAction($id, User::findByAttributes($params));
}

[MMSHFE]

من هم استفاده و معرفی ساختارهای جدید رو در سیمفونی تحسین میکنم ولی حرفم اینه که این مسئله نباید به قیمت زیر پا گذاشتن استانداردهایی که خیلی از برنامه های دیگه بر مبنای اونها دارن کار میکنن تموم بشه. مثلاً سیمفونی میتونست همین کار رو با ساختار JSON انجام بده و PHPDoc رو بهم نریزه و کدها هم خواناتر، قشنگتر و کوتاهتر میشد و از آرایه ها هم میشد پشتیانی کرد. حتی میتونست اون رو با ignore@ ترکیب کنه که بقیه برنامه ها اون رو نادیده بگیرن. مثال:

/**
* @ignore ["Security", "has_role('ROLE_ADMIN')"]
*/
public function helloAction($name)
{
// ...
}
مطمئنم منظورم رو درک میکنید. من میگم قابلیت خوب، خوبه، منتها به شرطی که خوب هم پیاده سازی بشه (و این خوب آخرین یعنی اینکه قبل از ساختارشکنی و تغییر استانداردهای موجود، مطمئن بشیم برنامه دیگری به اونها وابسته نیست و اگر هم هست، یا مرتبط با فیلد کاریمون نیست و یا اینکه درصد کمی ازش استفاده میکنن). برای مثال، همین PHPDoc درسته توی ایران کم استفاده میشه (توی ایران حتی کامنت هم توی کدها نمیگذاریم!) ولی برنامه نویسهای کشورهای دیگه خیلی باهاش سروکار دارن و مستندات رو باهاش Generate میکنن.

[bestirani2]

درسته و اینها همه قابلیتهای خوبی هست که سیمفونی داره ولی بطور کلی راه حل زیاده. ساخت annotaion اختصاصی تا وقتی خوبه که استانداردها رو بهم نزنه. مثلاً وقتی توی استاندارد PHPDoc مورد Security@ نداریم، هیچ کدی نباید به این استاندارد دست بزنه و خرابش کنه چون درسته که مزیتهایی برای کاربران داره ولی فرضاً یکسری قابلیتهای دیگه رو که بر اساس اون استاندارد بنا شدن، خراب میکنه و از کار میندازه.
بهرحال اون موردی که گفتین (یک اکشن به id احتیاج داشته باشه و یکی دیگه به یک مقدار دیگه)، میتونیم اینطوری توی Yii پوشش بدیم:
درسته که راهی که Symfony ارائه کرده ساده تره ولی قبول کنید برای کسی که برنامه نویسه، این راه هم کار خاصی نیست و پیچیدگی نداره و ازطرفی هم استانداردها رو بهم نمیزنه.


همونطور که گفتم استانداردش رو بهم نمیزنه و وقتی با PHPDoc داکیومنت رو تولید میکنید خبری از Security@ و ... نیست. تا اینجای کار تنوع مدل رو به کل گذاشتید کنار. حالا در همین مثال که گفتید فرض کنید یه مورد دیگه هم با get میگیرید مثل page که خیلی هم معمول هست. اتفاقی که میوفته اینه که برنامتون خطا میده یعنی باگ حتی اگه دیباگ رو هم خاموش کنید باز یه خطایی رو به شکل دلنشینتری نشون میده. این رو میشه درست کرد. این بره به کنار ببینید چند بار مجبور میشید کوئری بگیرید؟ حالا فرض کنید یکی از Get هایی که مد نظرتون نیست هم داخل جدولتون باشه. در نتیجه خطای منطقی رخ میده و نتیجه اشتباه رو به کاربر نشون میده.


من بالا بحثم همین بود کسی که برنامه نویسه به هر حال هر چیزی رو میتونه پیاده کنه. فریم ورک هم نیاز نیست. بحث سر خوانایی، قابلیت توسعه و نگهداری، انعطاف پذیری، قابلیت استفاده مجدد و ... هست. البته این مختص سیمفونی نیست توی دات نت فریم ورک، ruby و ... هم هست

حالا یه بحث قشنگتر به اسم Dependency Injection یا تزریق وابستگی . شما به جای این که مستقیم یه مدل یا ابجکت رو قرار بدید اینترفیسی رو قرار میدید که اون مدل از روی اون پیاده سازی شده.
حالا فرض کنید من برنامه رو پابلیش کردم برای عموم. از مدل یا ابجکتی که من استفاده کردم خوشش نمیاد؟ یه ابجکت و مدل جدید رو با توجه به اون اینترفیس درست میکنه و کنترل اون رو میشناسه بدون اینکه نیاز داشته باشه وارد کدهای من بشه و کنترلی که من نوشتم رو دستکاری کنه.

حالا شما میگید چه ایرادی داره دستکاری کنه یا اصلاً Extend کنه و اون قسمت رو مجدد overrid کنه. حالا من میام نسخه جدیدش رو پابلیش میکنم. میبینید که به بن بست میریسید.

[bestirani2]

من هم استفاده و معرفی ساختارهای جدید رو در سیمفونی تحسین میکنم ولی حرفم اینه که این مسئله نباید به قیمت زیر پا گذاشتن استانداردهایی که خیلی از برنامه های دیگه بر مبنای اونها دارن کار میکنن تموم بشه. مثلاً سیمفونی میتونست همین کار رو با ساختار JSON انجام بده و PHPDoc رو بهم نریزه و کدها هم خواناتر، قشنگتر و کوتاهتر میشد و از آرایه ها هم میشد پشتیانی کرد. حتی میتونست اون رو با ignore@ ترکیب کنه که بقیه برنامه ها اون رو نادیده بگیرن. مثال:

مطمئنم منظورم رو درک میکنید. من میگم قابلیت خوب، خوبه، منتها به شرطی که خوب هم پیاده سازی بشه (و این خوب آخرین یعنی اینکه قبل از ساختارشکنی و تغییر استانداردهای موجود، مطمئن بشیم برنامه دیگری به اونها وابسته نیست و اگر هم هست، یا مرتبط با فیلد کاریمون نیست و یا اینکه درصد کمی ازش استفاده میکنن). برای مثال، همین PHPDoc درسته توی ایران کم استفاده میشه (توی ایران حتی کامنت هم توی کدها نمیگذاریم!) ولی برنامه نویسهای کشورهای دیگه خیلی باهاش سروکار دارن و مستندات رو باهاش Generate میکنن.

اگه منظورتون PHp Doc هست تداخلی اینجاد نمیکنه. این موردی هم که من گفتم یکی از راه ها هست. شما میتونید با PHP، XMl و Yaml هم اینکار ها رو بکنید ولی خوانایی رو بهم میریزه. بقیه برنامه ها هم خودشون رو با سیمفونی تطبیق دادند مثلاً IDE ای که استفاده میکنم میاد رنگ annotation ها رو عوض میکنه و ...
خود من اتفاقاً با Php Doc کار میکنم. حتی یه باندل هم دانلود کردم که با یکی کلیک برای تولید میکنه و هیچ مشکلی از این بابت ندارم. دقیق نمیدونم خود Php Doc این موارد رو نادیده میگیره یا این باندل این کار رو انجام میده.
فرضا اگه نادید هم گرفته نشه فکر نکنم بد باشه توی داکیومنت این موارد بیاد. اینکه آدرس اکشن چیه؟ با چه متدی دریافت میشه و ...
به نظر من که خوبه. شاید اصلاً هدف سیمفونی این بوده که داکیومنت با اطلاعات بیشتری تولید بشه.

[MMSHFE]

درسته حق با شماست. بهرحال امکانات جدید سیمفونی زیاده و منصفانه هم اینه که با Yii 2 مورد مقایسه قرار بدیم که البته هنوز Release نشده ولی درهرحال فکر میکنم وقتشه از این موضوع بگذریم و سراغ سایر موارد بریم.

حالا در همین مثال که گفتید فرض کنید یه مورد دیگه هم با get میگیرید مثل page که خیلی هم معمول هست.
این هم راه حل داره:

public function runAction($id, $params = array()) {
foreach(array_keys($params) as $key) {
if(!in_array($key, array_keys(User::model()->attributeLabels))) {
unset($params[$key]);
}
}
$model = User::findByAttributes($params);
parent::runAction($id, $model);
}
که صد البته راه حل کاملی نیست و به کارآیی روش سیمفونی هم نیست و من هم همینطوری سرسری نوشتم تا بگم بهرحال راه حل داره و برنامه نویس واقعی لنگ اینجور چیزها نمیمونه اما باز هم تأکید میکنم ایجاد استانداردهای جدید نباید استانداردهای قبلی رو بهم بزنه. برای مثال من الآن توی کدهام Security@ رو اضافه کردم و PHPDoc Generator با تنظیمات پیشفرض خطا داد و برام مستندات رو تولید نکرد.
-----
درمورد Dependency Injection بیشتر با مثال توضیح بدین که ببینیم توی Yii راه معادل داره یا نه و توی 2 چیزی براش درنظر گرفته شده یا خیر.

[MMSHFE]

راستی یه سؤال برام پیش اومد. توی این کد:

/**
* @ParamConverter("post", class="SensioBlogBundle:Post")
*/
public function showAction(Post $post)
{
}
سیمفونی از کجا میفهمه پارامتر post$ مربوط به کدوم فیلد مدل Post هست و باید چطوری اون رو Load کنه؟ فرضاً اگه این پارامتر id نباشه و یک فیلد دیگه باشه چطور انجام میشه؟ یا اینکه فقط روی Primary Key میشه از ParamConverter استفاده کرد؟

[bestirani2]

درسته حق با شماست. بهرحال امکانات جدید سیمفونی زیاده و منصفانه هم اینه که با Yii 2 مورد مقایسه قرار بدیم که البته هنوز Release نشده ولی درهرحال فکر میکنم وقتشه از این موضوع بگذریم و سراغ سایر موارد بریم.

[/PHP]
که صد البته راه حل کاملی نیست و به کارآیی روش سیمفونی هم نیست و من هم همینطوری سرسری نوشتم تا بگم بهرحال راه حل داره و برنامه نویس واقعی لنگ اینجور چیزها نمیمونه اما باز هم تأکید میکنم ایجاد استانداردهای جدید نباید استانداردهای قبلی رو بهم بزنه. برای مثال من الآن توی کدهام Security@ رو اضافه کردم و PHPDoc Generator با تنظیمات پیشفرض خطا داد و برام مستندات رو تولید نکرد.
-----
درمورد Dependency Injection بیشتر با مثال توضیح بدین که ببینیم توی Yii راه معادل داره یا نه و توی 2 چیزی براش درنظر گرفته شده یا خیر.

درسته بالاترم خودم اشاره کردم که این راه حل داره و میره کنار. فرض بعدی رو روی این گذاشتم که یه get به طور اتفاقی داخل جدول باشه. مثلاً داخل جدولمون page هم داریم. ولی ما پست 8 رو لود کردیم و منظور از page تعداد صفحات مربوط به نظراتمون هست اینجا. حالا اتفاقی که میوفته و ما الان داخل صفحه 2 هستیم. اتفاقی که میفته اینه که به جای ایدی 8، آی دی 2 لود میشه. به هر حال بازم میگم که برای هر چیزی راهی هست حتی بدون فریم ورک. هدف از فریم ورک اینه که ما دیگه واسه پیدا کردن راه های شناخته شده که بقیه کشف کردند وقت نگذاریم و نظم و ترتیب خوبی داشته باشیم توی برناممون

همینطور که گفتم بهم نمیزنه. خودم دوباره تست کردم با باندل میشه اون قسمت ها رو حذف کرد و داکیومنت رو درست کرد ولی من ترجیح ام اینه که اون قسمت ها هم باشه چون به هر اطلاعتی داره میده. احتمالاً زیاد هدف سیمفونی هم همین بوده که این مدلی قرار داده کدش رو تا بتونیم داکیومنت کاملتری داشته باشیم. الان میدونیم هر اکشن کیا دسترسی دارند، ادرسش چیه و ...

در ضمن Php Doc تگ ناشناخته رو هم قبول میکنه و فقط مربوط به سیمفونی نیست. میتونید هر چیزی رو اضافه کنید.

117188

عکس رو ببینید برای securityCheckAction به صورت فرضی @return int قرار دادم که توی عکس کاملا مشخص هست که return رو اورده و کنارش قسمتی به عنوان tag داره که اونجا Security و Route هم اورده که به نظرم این برای داکیومنت خوبه

برای توضیحات بیشتر لینک زیر رو بخونید

http://www.mojsazan.com/forum/showthread.php?tid=3308

[bestirani2]

راستی یه سؤال برام پیش اومد. توی این کد:

سیمفونی از کجا میفهمه پارامتر post$ مربوط به کدوم فیلد مدل Post هست و باید چطوری اون رو Load کنه؟ فرضاً اگه این پارامتر id نباشه و یک فیلد دیگه باشه چطور انجام میشه؟ یا اینکه فقط روی Primary Key میشه از ParamConverter استفاده کرد؟

خوشبختانه سیمفونی فکر همه جا رو کرده



/** * @Route("/blog/{post_id}") * @ParamConverter("post", class="SensioBlogBundle:Post", options={"title" = "post_title"}) */public function showAction(Post $post){}

الان title رو get میکنه و به عنوان post_title قرار میده. حتی میشه نوع مدیریت دیتابیس اش هم عوض کرد. پیش فرض روی Doctrine هست. حالا فرضا شما داری با Mongodb کار میکنی. راحت عوض میکنی.
خیلی اتعطاف پذیرتر از این چیزها هست. یه مثال دیگه میزنم تا انعطاف پذیریش رو ببینید.



/** * @Route("/blog/archive/{start}/{end}") * @ParamConverter("start", options={"format": "Y-m-d"}) * @ParamConverter("end", options={"format": "Y-m-d"}) */public function archiveAction(\DateTime $start, \DateTime $end){}

حالا شما میتونید اختصاصی خودتونم تولید کنید. مثلاْ یکی تولید میکنید که باعث تولید RestFul میشه و دیگه نیاز نیست کلی کد بزنید از طرفی توی داکیومنت هم این موضوع رو میبینید. پس بهتره این موارد توی داکیومنت باقی بمونه.

راستی دلیلی که از تگ cSharp به جای php برای قرار دادن کد استفاده میکردم این بود که داخل تک php خط جدید نمی افتاد و اسکرول میخورد مثل الان

[bestirani2]

درسته حق با شماست. بهرحال امکانات جدید سیمفونی زیاده و منصفانه هم اینه که با Yii 2 مورد مقایسه قرار بدیم که البته هنوز Release نشده



البته خیلی هم جدید نیست. نسخه دومش دو سال پیش منتشر شده که بیشتر این امکانات رو با خودش داشت.
YII 2 پیشرفت زیادی کرده. من یه دور کامل داکیومنتش رو خودنم ولی باز به نظر من از نظر enterprise بدون خیلی با سیمفونی فاصله داره. البته من خودم خیلی YII رو دوست دارم ولی هدف این دو تا فریم ورک فرق داره. سیمفونی هدفش enterprise بوده که همینطورم هست. حتی توی نسخه یکش به شدت پرفورمنس اش پایین بود که اصلاْ برای پروژه های کوچیک و متوسط به صرفه نبود ولی توی نسخه ۲ بهبود خوبی پیدا کرد به طوری که در پروژه های واقعی خیلی کم پرفورمنسش با YII فاصله داره که طبق وبلاگ خود سیمفونی بعد از انتشار نسخه ۲، از الان میتونید سیمفونی رو برای پروژه های کوچک و متوسط خود هم استفاده کنید یعنی اینکه سیمفونی خودش رو تا قبل از نسخه ۲ فقط برای پروژه های بزرگ حساب میکرده و کلی پروژه بزرگ هم باهاش ایجاد شده ولی YII هدفش این بوده در کمترین زمان بتونید یه سایت با پرفرمنس خوب تولید کنید که موفق هم بوده و واسه پروژه های کوچیک و تا حدودی متوسط عالیه.
اینم بگم تا YII 2 بیاد سیمفونی کلی امکانات جدید گرفته. سیمفونی همگام با امکاناتی که در نسخه های Php معرفی میشه و استاندارد های جدید مهندسی آپدیت میشه. مثلاْ به غیر از سیمفونی کدوم فریم ورک از Trait پشتیبانی میکنه؟ پی اچ پی ۵.۳ هم اومد اولین فریم ورک سیمفونی بود که رفت سمت نیم اسپس و ..
پشتیبانی واسه پروژه های بزرگ خیلی مهمه
شما برید
http://symfony.com/roadmap?version=2.5
و ورژن مورد نظرتون رو بزنید تا بفهمید کی منتشر میشه این یعنی نظم

[bestirani2]

نه دیگه نشد، ببینید الآن شما اومدین این متدها رو توی کلاس جداگانه گذاشتین و اگه قرار به این کار باشه توی Yii هم میشه کلاً سطح دسترسی متدهای یک کنترلر خاص رو توی کنترلر والد (components/Controller) تعریف کرد. تقاضا میکنم مثل حالت معمول Yii شما هم همه متدهای یک کنترلر رو توی یک کلاس بگذارین کنار بقیه متدها و سطح دسترسیهای هرکدوم رو مشخص کنید.

این رو الان دیدم؟ منظورتون رو نفهمیدم؟ کلاس جدا؟ کنترلم هست. اکشن های میره توی کنترل. شما هم آرایه مربوط به فیلتر و ... رو توی کنترل تعریف میکنید. اینجا منم برای اینکه به کل اکشن های کنترل اعمال بشه. به جای اینکه دونه دونه بالای هر اکشن بگذارم، میگذارم بالای کل کنترل و چیز جدیدی اینجا تعریف نشده. احتمالاْ منظور من رو بعد فهمیدید. البته الان اگه نیاز به این باشه یه قسمت به نوع دیگه عمل کنه باید مجدد برای همون اکشن تعریف کنیم.

اگرم بخواید حتی میتونید به صورت یکپارچه با کمک عبارت منظم داخل تنظیمات تعیین کنید.


access_control:
- { path: ^/login, roles: IS_AUTHENTICATED_ANONYMOUSLY }
- { path: ^/, roles: ROLE_ADMIN


الان اینجا تعیین شده اگه ادرس وارد شده لاگین باشه هر کسی بتونه وارد بشه ولی بقیه مسیرها رو فقط کسانی که دسترسی ادمین دارند بتونند وارد بشند.

یا مثلاْ میتونید بگید. صفحاتی که درون ادرسشون ادمین هست رو فقط نقش ادمین وارد بشه و بقیه صفحات رو هر کسی بتونه باز کنه که من خودم به شخصه استفاده از حاشیه نویسی رو ترجیح میدم تا این حالت. توی حالت قبل ویرایش کد خیلی راحتره و برای اینکه بدونید الان چه اتفاقی میفته لازم نیست به برید تابع فیلتر رو پیدا کنید یا توی تنظیمات بگردید.

[MMSHFE]

خوب اینکه یکبار بطور کلی برای همه متدها سطح دسترسی تعیین بشه و بعد برای متدهایی که فرق میکنن، جداگانه ذکر کنیم توی Yii هم هست (میدونید که میشه actions رو ننوشت تا Rule به همه اکشنها اعمال بشه). درهرصورت مشکلی ازنظر کارایی و راحتی کارکرد توی سینتکس Yii نمیبینم (هرچند قبول دارم سیمفونی مهندسی شده تر عمل کرده). بهرصورت من هم مثل شما Yii رو برای پروژه های کوچک تا متوسط و حتی پروژه های بزرگ (البته نه خیلی بزرگ و سنگین) مناسب میدونم و ساختار سیمفونی رو برای پروژه های سنگینی که بخواد بصورت تیمی و چند نفره روش کار بشه مناسب میدونم و معتقدم توی پروژه های معمولی (که 90٪ کاربردها رو تشکیل میدن)، بیشتر دست و پاگیره تا کار راه انداز. البته شخصاً با Yii پروژه های خیلی سنگین هم انجام دادم و همین الآن هم مشغول یکیشون هستم و انصافاً اذیتم نکرده.

[bestirani2]

خوب اینکه یکبار بطور کلی برای همه متدها سطح دسترسی تعیین بشه و بعد برای متدهایی که فرق میکنن، جداگانه ذکر کنیم توی Yii هم هست (میدونید که میشه actions رو ننوشت تا Rule به همه اکشنها اعمال بشه). درهرصورت مشکلی ازنظر کارایی و راحتی کارکرد توی سینتکس Yii نمیبینم (هرچند قبول دارم سیمفونی مهندسی شده تر عمل کرده). بهرصورت من هم مثل شما Yii رو برای پروژه های کوچک تا متوسط و حتی پروژه های بزرگ (البته نه خیلی بزرگ و سنگین) مناسب میدونم و ساختار سیمفونی رو برای پروژه های سنگینی که بخواد بصورت تیمی و چند نفره روش کار بشه مناسب میدونم و معتقدم توی پروژه های معمولی (که 90٪ کاربردها رو تشکیل میدن)، بیشتر دست و پاگیره تا کار راه انداز. البته شخصاً با Yii پروژه های خیلی سنگین هم انجام دادم و همین الآن هم مشغول یکیشون هستم و انصافاً اذیتم نکرده.
میدونم معادل YII هم داره حتی میشه به جای + از - استفاده کرد تا شامل اون کنترل ها نشه. من منظورم قسمتی بود که گفتید اینکه قبول نیست جدا جدا تعریف کنید. همین کار ها رو توی سیمفونی هم میکنیم منتهی با annotion
باید دید تعریف شما از پروژه بزرگ چی هست؟ با YII تا حالا یه پروژه 10 نفری جلو بردید؟ حالا فرض کنید شما نفر یازدهم پروژه هستید؟ راحت میتونید پروژه رو درک کنید؟ البته از نظر من برای پروژه های کوچک و متوسط هم دست پا گیر نیست البته به شرطی که لایه روی سیمفونی درست کنیم که خیلی از جاها سرعتمون رو ببره بالاتر. یه همچین کاری رو واسه YII انجام داده بودم که سرعتم بیشتر بشه + باندل های قوی ای براش وجود داره که قوی تر از نمونه مشابهش برای YII هست. مثلاً برای مدیریت یوزر کامل همه چیز رو میشه کنترل کرد از فیلد هایی که قرار هست داخلش قرار بگیره تا ویویی که قرار رندر بشه و ... هر چیزی رو میشه کنترل کرد. یا باندلی واسه درست کردن محتوی داره و با چند خط کد میشه هر نوع محتوی ای مثلاً بلاگ، فروشگاه و ... رو درست کرد و ....

[MMSHFE]

راستش بزرگترین پروژه ای که تابحال توی شرکت خودم روش کار کردم یک پروژه بود که با یک تیم 15 نفره انجام دادیم و 3 نفر کارهای طراحی و UI رو بعهده داشتن و 7 نفر برنامه نویس بودیم که یکیشون که خودم بودم، مدیر پروژه هم بودم و 5 نفر هم کارهای متفرقه مثل بازاریابی و پشتیبانی و تأمین منابع (مثل فایلها و فونتهای موردنیاز و...) رو انجام میدادن و کلاً این پروژه رو بصورت ماژولار با Yii انجام دادیم که یک سیستم مدیریت آگهی هوشمند بود و البته یکسری ریزه کاریها داره و هنوز تمام نشده و تا حالا هم مشکلی نداشتیم چون همونطور که گفتم، اولاً خودم از اول روی پروژه ناظر بودم و درنتیجه همه رو مجبور به درج PHPDocهای مناسب برای تمام بخشهای کد کردم و ثانیاً اگه کسی بعداً بخواد اضافه بشه، بخاطر وجود مستندات حرفه ای که بطور خودکار از روی کدها تولید میشه و انجام کارها با فریمورک و مخصوصاً کارکردن بصورت ماژولار و استفاده از Migrationها در دیتابیس و SVN در فایلهای سورس، بعید میدونم مشکل خاصی داشته باشه. درهرصورت گفتم که قبول دارم ساختار Symfony خیلی خیلی مهندسی شده است و خوبه ولی باز هم تأکید میکنم بندرت (حداقل توی ایران) پروژه ای پیدا میشه که به این سطح از سختگیریهای کاری احتیاج پیدا کنه و Yii به خوبی از عهده اینجور پروژه ها بر میاد. برای مثال همین امکاناتی که گفتین (مثل بلاگ و فروشگاه و...) رو هم میشه با ماژولهای Yii مدیریت کرد و انجام داد.

[bestirani2]

راستش بزرگترین پروژه ای که تابحال توی شرکت خودم روش کار کردم یک پروژه بود که با یک تیم 15 نفره انجام دادیم و 3 نفر کارهای طراحی و UI رو بعهده داشتن و 7 نفر برنامه نویس بودیم که یکیشون که خودم بودم، مدیر پروژه هم بودم و 5 نفر هم کارهای متفرقه مثل بازاریابی و پشتیبانی و تأمین منابع (مثل فایلها و فونتهای موردنیاز و...) رو انجام میدادن و کلاً این پروژه رو بصورت ماژولار با Yii انجام دادیم که یک سیستم مدیریت آگهی هوشمند بود و البته یکسری ریزه کاریها داره و هنوز تمام نشده و تا حالا هم مشکلی نداشتیم چون همونطور که گفتم، اولاً خودم از اول روی پروژه ناظر بودم و درنتیجه همه رو مجبور به درج PHPDocهای مناسب برای تمام بخشهای کد کردم و ثانیاً اگه کسی بعداً بخواد اضافه بشه، بخاطر وجود مستندات حرفه ای که بطور خودکار از روی کدها تولید میشه و انجام کارها با فریمورک و مخصوصاً کارکردن بصورت ماژولار و استفاده از Migrationها در دیتابیس و SVN در فایلهای سورس، بعید میدونم مشکل خاصی داشته باشه. درهرصورت گفتم که قبول دارم ساختار Symfony خیلی خیلی مهندسی شده است و خوبه ولی باز هم تأکید میکنم بندرت (حداقل توی ایران) پروژه ای پیدا میشه که به این سطح از سختگیریهای کاری احتیاج پیدا کنه و Yii به خوبی از عهده اینجور پروژه ها بر میاد. برای مثال همین امکاناتی که گفتین (مثل بلاگ و فروشگاه و...) رو هم میشه با ماژولهای Yii مدیریت کرد و انجام داد.
موافقم پروژه ای که توی ایران به قدرت سیمفونی احتیاج داشته باشه خیلی کمه ولی در حین قدرت اصلاً دست و پا گیر نیست و وقتی یاد بگیرید خیلی بهتر از هر چیزی هست ولی بحثی که اینجا مطرح هست زمان یادگیری هست که زیاده به دلیل پیچیدگی های مهندسی ای که سیمفونی داره و برای پروژه های ایران به صرفه نیست یادگیریش به بیان دیگه وقتی YII برای پروژه هایی که هست کافیه چرا چند برابر زمان برای یادگیری صرف کنیم؟ ولی اگه کسی قصد رفتن به بازار کار خارج از ایران رو داشته باشه، بازار کار خیلی خوبی داره.