implement Future

[Zero]

Coding nhiều quá mệt, ai giải trí tí không ?

Giải trí: implement ý tưởng sau.

MathRPC m = new MathRPC(); 

Future<int> x = m.Sum (1, 2);
Future<int> y = m.Sum (3, 4);

Assert.AreEqual (3, x.Value);
Assert.AreEqual (7, y.Value);

Assert.AreEqual (1, m.RemoteCall);

Hay thực tế hơn:

Future<IList<Item>> items = itemService.GetAll();
Future<IList<Category>> categories = categoryService.GetAll();

DataBind();

Assert.AreEqual (1, database.Queries);

Câu hỏi khác: có cách nào batch-processing đẹp hơn ko ?

[root1984]

Đoạn peusdo code này khó hiểu quá giải thích cụ thể nữa được ko?

[Zero]

@root1984:

Math:

m ở đây là 1 remote service (RPC), ở đây có 2 call đến Sum --> 2 remote call, yêu cầu ở đây là 1 remote call.

Database:

ItemService và CategoryService là 2 service sử dụng database, bình thường sẽ cần 2 lần gọi đến database.

Ý tưởng ở đây là Batch-Processing, gom request lại rồi xử lí 1 cục , vấn đề là implement sao cho đẹp, code vẫn tự nhiên.

[root1984]

MathRPC m = new MathRPC();

Transaction t = m.BeginTransaction();

t.Queue(m.Sum, 3, 4);
t.Queue(m.Sum, 5, 7);

t.Commit(); //RealCall

if Exception

t.RollBack();

Cach nay thi binh thuong roi. cai Future implement the nao duoc nhi?

[Zero]

Bạn phải implement để đoạn code 1 chạy cơ : D. (MathRPC và Future<T>)

[bienca101]

Ôi, phức tạp nhở?

Sao ko quăng mấy cái generics đi và dùng params overload thế này này:

interface IMathRPC
{
Future Sum(int a, b);
IList Sum(params int[] values);
}

Vậy thì lúc lấy kết quả là thế này:
IList futures = m.Sum(1, 2, 3, 4);

Còn lý do tại sao quăng Generics là vì trong trường hợp dùng RPC ở đây, generics có vẻ được đưa vô vì lười
Và ngoài ra, khi nào có chữ remote vào đấy thì nên tránh generics hoặc làm phức tạp hóa vấn đề đi.

[Zero]

Còn lý do tại sao quăng Generics là vì trong trường hợp dùng RPC ở đây, generics có vẻ được đưa vô vì lười
Và ngoài ra, khi nào có chữ remote vào đấy thì nên tránh generics hoặc làm phức tạp hóa vấn đề đi.

Nhìn code cho đẹp.

Call thực sự là generic hay không thì tùy implement cơ mà ?

interface IMathRPC
{
Future Sum(int a, b);
IList Sum(params int[] values);
}

Vậy thì lúc lấy kết quả là thế này:
IList futures = m.Sum(1, 2, 3, 4);

Ý anh không phải là code của User sẽ thành ?

IList futures = m.Sum (1, 2, 3, 4) ?

[bienca101]

ừa, ý mình là code của user sẽ vậy đó.

Còn nếu muốn dã man thì thế này đi cho sang:

    RemoteContainer
    {
          Enqueque(workItem);
          IList ExecuteWorks();
          
          hoặc
          void ExecuteWorks(callback)
    }
    
    MathRPC : RemoteContainer {}
    {
          Sum(a, b)
          {
              Enqueque(SumWork(a,b));
          }
    }

User code:

    m.Sum(1, 2);
    m.Sum(3, 4);    

    IList futures = m.ExecuteWorks();

    hoặc
    m.ExecuteWorks(callback);

Đấy, vậy thì giải quyết luôn 1 lần cả remoting lẫn threading nhá. Muốn đẹp đẹp thì cho Lamda expression vào để user đỡ mất công.

[Zero]

ừa, ý mình là code của user sẽ vậy đó.

Còn nếu muốn dã man thì thế này đi cho sang:

    RemoteContainer
    {
          Enqueque(workItem);
          IList ExecuteWorks();
          
          hoặc
          void ExecuteWorks(callback)
    }
    
    MathRPC : RemoteContainer {}
    {
          Sum(a, b)
          {
              Enqueque(SumWork(a,b));
          }
    }

User code:

    m.Sum(1, 2);
    m.Sum(3, 4);    

    IList futures = m.ExecuteWorks();

    hoặc
    m.ExecuteWorks(callback);

Đấy, vậy thì giải quyết luôn 1 lần cả remoting lẫn threading nhá. Muốn đẹp đẹp thì cho Lamda expression vào để user đỡ mất công.

Thế này thì không nói rồi.

Chắc anh hiểu nhầm ý em: ở đây là batch-processing mà code của dev ko cần phải aware về chuyện đó ?

Câu hỏi khác: thực ra có nên làm vậy ko ? (không biết ở dưới nền đc batch-process)

[bienca101]

Chài, bữa nay tui với chú rảnh chuyện quá, vô forum này hoài hén

Về mặt design, quan điểm của tui là fw ko nên ôm hết mọi chuyện mà càng đơn giản càng tốt vì optimize tốt nhất là khi có khả năng extensible nhất.

Tuy nhiên, về thực tế, thường thường devs rất hay sử dụng nhầm hoặc thậm chí ko biết xài. Cho nên fw nên abstract đi để devs ko biết gì cả.

Nếu thời gian cho phép, tui ráng lụm luôn cả 2 cách làm, abstract layer bên dưới thì extensible các kiểu, sau đó thêm 1 facade layer phía trên để devs ko cần biết gì hết. (Mà thực ra cũng nên thế thật, vì lắm lúc chính mình còn ko nhớ cách xài, cho nên cứ quăng vài cái helper ra, chứ mỗi lần muốn xài lại phải mở source code ra coi, quê)