SIM đa năng Flame bắn tiền 7 mạng,nạp phí 4 game:
* Thao tác đơn giản, không cú pháp nhắn tin.
* Bắn tiền trực tiếp cho 7 mạng điện thoại: Viettel, Vinaphone, MobiFone (cả trả trước và trả sau), Sfone, Vietnamobile, EVN.
* Nạp phí 4 game: Vinagame (zing xu), VTV Online (.....), FPT Online (Bac) và Oncash đa năng (Oncash, Silk).
- HÌNH THỨC KINH DOANH:
Khi gia nhập bạn sẽ mua 1 SIM 550.000 VNĐ trong đó có:
- Phí gia nhập 220.000 VNĐ.
- Tài khoản nghe gọi 130.000 VNĐ, SIM đầu số 0120, gói cước 365, bạn có 365 ngày nghe, gọi miễn phí cước thuê bao.
- Tài khoản kinh doanh: Có sẵn 200.000 VNĐ trong tài khoản bán hàng:
Từ 1 SIM Flame bạn mua, bạn sẽ phát triển những người bạn quen cửa hàng bán tạp hóa,… sẽ có cơ hội phát triển thành điểm kinh doanh của bạn.
* Hoa hồng hấp dẫn từ việc phát triển sim:
Khi bạn giới thiệu trực tiếp 1 SIM bạn sẽ được thưởng 50.000 VNĐ ngay lập tức cộng vào tài khoản kinh doanh của bạn, gián tiếp (tức tầng 2 của bạn) bạn sẽ được thưởng 25.000 VNĐ, tầng 3 thưởng 15.000 VNĐ, tầng 4 thưởng 10.000 VNĐ, tầng 5 thưởng 5.000 VNĐ.
* Chiết khấu bán hàng hưởng từ 5.6 - 9.5% tùy theo mạng điện thoại bạn bắn tiền.
VD: Bạn bán mệnh giá 100.000 VNĐ cho mạng MobiFone bạn sẽ thu của khách hàng 100.000 VNĐ nhưng trong tài khoản kinh doanh của bạn bị trừ đi 93,800 VNĐ tức là bạn đã được 6,2% hưởng ngay lập tức. (Thuê bao nhận tiền vẫn được hưởng các khuyến mại của nhà mạng như khi nạp tiền bằng thẻ cứng).
* Thưởng phát triển hệ thống:
Khi hệ thống của bạn phát triển đc 100 sim thưởng 3 triệu đồng (Lĩnh 1 lần vào ngaỳ 05 của tháng tiếp theo) và hưởng 0.5% doanh số bán hàng của SIM có giao dịch với điều kiện hệ thống của bạn phải có > hoặc= 100 SIM có giao dịch.
Trong hệ thống của bạn có nhóm nào đạt 100 sim tách ra thì bạn sẽ được thưởng 2 triệu đồng và hưởng 0.1% doanh số bán hàng của nhóm đó và nhóm đó sẽ được hưởng quyền lợi giống như trên.
Và bạn sẽ được hưởng doanh số bán hàng hết tầng 3.
Mức thưởng hệ thống khi không có nhóm tách:
+ 100 SIM thưởng 3 triệu đồng.
+ 300 SIM thưởng 5 triệu đồng.
+ 500 SIM thưởng 10 triệu đồng.
+ 1000 SIM thưởng 20 triệu đồng.
Liên hệ: Y!M: handsomeboyltv
SDT: 01207 4004 66
Chúc các bạn thành công!
4 thg 5, 2011
12 thg 5, 2010
Mô hình MVP
Trong Quá trình xử lí quá trình tách biệt các thành phần xử lí khỏi hệ thống UI là rất cần thiết, tạo ra khả năng xử lí độc lập cho UI.
Việc tách rời dữ liệu khỏi UI sẻ tạo ra được nhiều UI khác nhau cho các cách thể hiện khác nhau.
Code xử lý đặt trong UI gây khó khăn cho việc kiểm tra và gây phức tạp và trùng lập code. Việc kiểm tra các UI thường hoặc phải chạy ứng dụng thủ công hoặc sử dụng kịch bản (script) để thực hiện việc tương tác tự động lên các UI, do đó sẽ tốn nhiều chi phí và thời gian hơn để kiểm tra các xử lý bên trong thành phần này.
Việc tách các xử lý này ra ngoài ra còn tăng tính tái sử dụng code và dễ bảo trì hơn.
Phương pháp để giải quyết là dùng kiến trúc MVC (Model-View-Controller) và một mẫu kiến trúc thừa kế là MVP, hiện được ứng dụng rộng rãi trong môi trường .NET.
Mẫu kiến trúc Model-View-Controller chia nhỏ các thành phần dữ liệu, thể hiện (output) và dữ liệu nhập từ người dùng (input) thành những thành phần riêng biệt.
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic). Thành phần model thường được trình bày ở dạng Domain Model.
View là thành phần đảm nhận việc thể hiện những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form... Trên cùng một Model, có thể có nhiều View.
Controller là thành phần đảm nhận việc xử lý đáp trả lại các dữ liệu được đưa vào từ người dùng như các sự kiện chuột, bàn phím, các tương tác lên các control... Controller là cầu nối giữa người dùng và ứng dụng.
Sự phụ thuộc của Model vào các thành phần khác và tại một thời điểm khó xác định điều gì sẽ xảy ra khi đọc code và việc kiểm tra cũng khó khăn hơn.
Kiến trúc MVP dựa trên tư tưởng cơ bản của MVC nhưng với cách tiếp cận khác nhằm khắc phục các hạn chế của MVC cổ điển.
Các thành phần của MVP
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới.
View là thành phần đảm nhận việc thể hiện những dữ liệu của Model và là tổng hợp của các form, control được sử dụng.
Presenter là thành phần đảm nhận các xử lý thể hiện cũng như tương tác đến dữ liệu bên dưới và có thể tương tác để thay đổi View trong quá trình xử lý.
Phối hợp các thành phần
Mẫu kiến trúc MVP của Microsoft tương tự như Passive View nhưng có bổ sung ràng buộc là Presenter chỉ có thể truy cập đến View thông qua interface IView. Điều này giúp Presenter không phụ thuộc đến cài đặt cụ thể của View và có thể dễ dàng kiểm tra Presenter một cách độc lập.
Mối quan hệ giữa Presenter và Model là quan hệ một chiều (chiều còn lại là gián tiếp). Hệ quả là chúng ta có một mô hình đa lớp như cấu trúc ở trên theo ý nghĩa các thành phần ở một lớp chỉ phụ thuộc và sử dụng các thành phần ở lớp ngay bên dưới nó.
Với MVP, một View gắn liền với một interface IView. Khi View được tạo ra, nó tạo ra một đối tượng private Presenter và gắn nó vào đối tượng này thông qua IView. Khi một sự kiện xảy ra, View bắt lấy và sau đó kích hoạt một phương thức của Presenter mà sau đó có thể tương tác với Model. Một số sự kiện như bắt đầu hiển thị và đóng của View cũng được gửi tới để Presenter kích hoạt một số phương thức tương ứng, điều này giúp cho một số công việc như khởi tạo và giải phóng dữ liệu cho View được dễ dàng hơn. Model được tổ chức bổ sung một lớp Service nằm bên trên để tương tác với Presenter.
Việc tách rời dữ liệu khỏi UI sẻ tạo ra được nhiều UI khác nhau cho các cách thể hiện khác nhau.
Code xử lý đặt trong UI gây khó khăn cho việc kiểm tra và gây phức tạp và trùng lập code. Việc kiểm tra các UI thường hoặc phải chạy ứng dụng thủ công hoặc sử dụng kịch bản (script) để thực hiện việc tương tác tự động lên các UI, do đó sẽ tốn nhiều chi phí và thời gian hơn để kiểm tra các xử lý bên trong thành phần này.
Việc tách các xử lý này ra ngoài ra còn tăng tính tái sử dụng code và dễ bảo trì hơn.
Phương pháp để giải quyết là dùng kiến trúc MVC (Model-View-Controller) và một mẫu kiến trúc thừa kế là MVP, hiện được ứng dụng rộng rãi trong môi trường .NET.
Mẫu kiến trúc Model-View-Controller chia nhỏ các thành phần dữ liệu, thể hiện (output) và dữ liệu nhập từ người dùng (input) thành những thành phần riêng biệt.
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới (business logic). Thành phần model thường được trình bày ở dạng Domain Model.
View là thành phần đảm nhận việc thể hiện những dữ liệu của Model. View bao gồm những gì thể hiện trên màn hình như các control, form... Trên cùng một Model, có thể có nhiều View.
Controller là thành phần đảm nhận việc xử lý đáp trả lại các dữ liệu được đưa vào từ người dùng như các sự kiện chuột, bàn phím, các tương tác lên các control... Controller là cầu nối giữa người dùng và ứng dụng.
Sự phụ thuộc của Model vào các thành phần khác và tại một thời điểm khó xác định điều gì sẽ xảy ra khi đọc code và việc kiểm tra cũng khó khăn hơn.
Kiến trúc MVP dựa trên tư tưởng cơ bản của MVC nhưng với cách tiếp cận khác nhằm khắc phục các hạn chế của MVC cổ điển.
Các thành phần của MVP
Model chứa dữ liệu và các tính toán xử lý logic để giải quyết vấn đề mà phần mềm hướng tới.
View là thành phần đảm nhận việc thể hiện những dữ liệu của Model và là tổng hợp của các form, control được sử dụng.
Presenter là thành phần đảm nhận các xử lý thể hiện cũng như tương tác đến dữ liệu bên dưới và có thể tương tác để thay đổi View trong quá trình xử lý.
Phối hợp các thành phần
Mẫu kiến trúc MVP của Microsoft tương tự như Passive View nhưng có bổ sung ràng buộc là Presenter chỉ có thể truy cập đến View thông qua interface IView. Điều này giúp Presenter không phụ thuộc đến cài đặt cụ thể của View và có thể dễ dàng kiểm tra Presenter một cách độc lập.
Mối quan hệ giữa Presenter và Model là quan hệ một chiều (chiều còn lại là gián tiếp). Hệ quả là chúng ta có một mô hình đa lớp như cấu trúc ở trên theo ý nghĩa các thành phần ở một lớp chỉ phụ thuộc và sử dụng các thành phần ở lớp ngay bên dưới nó.
Với MVP, một View gắn liền với một interface IView. Khi View được tạo ra, nó tạo ra một đối tượng private Presenter và gắn nó vào đối tượng này thông qua IView. Khi một sự kiện xảy ra, View bắt lấy và sau đó kích hoạt một phương thức của Presenter mà sau đó có thể tương tác với Model. Một số sự kiện như bắt đầu hiển thị và đóng của View cũng được gửi tới để Presenter kích hoạt một số phương thức tương ứng, điều này giúp cho một số công việc như khởi tạo và giải phóng dữ liệu cho View được dễ dàng hơn. Model được tổ chức bổ sung một lớp Service nằm bên trên để tương tác với Presenter.
Đăng ký:
Bài đăng (Atom)