Correct, I agree with you. Sometimes we cannot afford a layered architecture. It is not practical also. Architecture should be based on Application demand. Thanks for pointing this out.

Have you looked at the Settings of the Project Properties? This is usually where you would store user configuration settings.

In my thinking of using ORM for inventory control, it should be get a stock, minus the request quantity, and then update to the database. so if inventory = 6 pc a = 6, pc b = 6, then pc a request to remove 2 items and process the value = 4 and then update to db, but pc b keep the value = 6 and then remove 3 items, and the update to db, it seen to be value = 3 in the inventory, it's about the concurrency control, how to let it better? Thanks

FYI, I've read on and noticed you need this to work with MSSQL Server 2000. You've said little about your scenario so it's a bit tricky to give any advice. So this is just some general info instead. The database does not provide anything that makes it directly easy to provide an event in your application. It is possible though. One way is to write an extended stored procedure in C++ that notifies your application (for example using a message queue) that the update has taken place, and then call this from a trigger in the database. Another option is available if the database is (supposed to be) accessed only via your client app and you can update all installed clients before the feature becomes (fully) functional. In this case you could use remoting or message queues or web services or even sockets (if you like to needlessly complicate things and reinvent the wheel :)) to notify all clients when any client has just modified the data in question. To be honest, I think polling is a better option. Just remember that if you've got loads of clients and poll frequently it will generate considerable load on the database and it may be smart to put a caching server in the middle. 500 clients polling every 5 seconds is 100 requests per second. If you've got such a case, consider making an app that polls the db every 5 seconds and updates a cached value (such as a timestamp). Then clients can poll this app (which of course responds based on the cached information) without having to acquire shared locks in the database and the rest of the overhead of executing some query a hundred times per second.

Some of that is already applied but the controller is too large, I think it contains a lot of "Get Data from Model and Give it to View" code in the controller. e.g. for payment, the view should load all PaymentMethod, all Branch and all division for user selection and bound the Payment object with Payment details, so the controller for this case contain GetAllPaymentMethod(), GetAllBranch(), GetAllDivision() for user selection Some of other part of the application contain more then three GetXXX() so it become too large, so I want to clarify about it. 1. Should controller handle object creation method? I have already separated a Factory Class for object creation, but should view directly call the factory or call the controller to create object from factory? 2. Should controller handle GetAllXXX() method for user selection? or let view call it directly? 3. Should controller handle flow between object and DAO? e.g. Update(Payment obj) { PaymentDao.Update(obj);} 4. Should controller provide interface for domain model method? e.g. ShipOrder(Order obj) { order.Ship(); orderDao.Update(order);} Thanks

but if CompanyA is software house, CompanyB is the client and will not see that namespace, is it a good practice to keep CompanyB in the namespace to indicate the customized project is for CompanyB?

If a method has no side effects, and fetches something in a fairly straightforward manner (it shouldn't read a database or something), yes, consider using a property instead. Cheers, Vıkram. Stand up to be seen. Speak up to be heard. Shut up to be appreciated.

Thank you very much~~ :):):):)