CSLA .NET

---

Rocky

RockfordLhotka:

If you or your purchasing agent is having trouble with the ebooks, they should email admin at Lhotka.net for help.

Rocky

Yes, it seems that there is a problem. I asked the person in charge to send email to the address you gave me.

In the mean time, could you please tell me if there is a way to purchase such books as Normal Books (not eBooks) from some other webstore ?

It seems that not all Books of CSLA are available in Amazon webstore.

The order of the book "Expert VB Business Objects" is submitted from Amazon.com and expexted to arrive soon.

Tarek.

---

Rocky

Ok, will take care of the books.

I have started making some effort on Windows Authenticaiton with CSLA.

If you have some time, please check the details here:

http://forums.lhotka.net/forums/22785/ShowThread.aspx#22785

I appreciate your comments.

Tarek.

I managed to implement Mixed Authentication successfully in addition to developing a simple new BO. Check details here:

http://forums.lhotka.net/forums/22855/ShowThread.aspx#22855

I appreciate your comments if there is something wrong in my approach.

I have the following very important questions, and appreciate your reply:

1. In the PTracker Sample Application, and in the new Sample Application I developed, I had some doubt about how to set a reference to CSLA DLLs. In the instructions for installing the application, it was mentioned to deploy the DLL to the GAC. But, I did not do that, because I do not know how, so I just simply set a reference to CSLA DLLs by Browsing to the csla.dll file from the csla project bin folder, after building it. Is this correct ? Is it absolutely necessary to deploy csla dll to CAG and use Strong Key or something like that ?

- When I set a reference to the csla dll from the Web Project, several DLLs showed in the references for different languages. But, in the Library Project, after setting the reference to csla dll, only one reference appeared ? Can you  please explain this ?

2. Suppose I have several applications using CSLA Framework. Each application is developed locally on a separate PC, and eventually they must be deployed to one Server Machine. What is the best way to reference the DLL ? All must reference the same file, or they must have a separate copy of the file in the BIN folder ? Will be there any problems for threading conflicts ? My colleague told me that referencing the different copies of the DLL will cause some kind of threading conflict (same code being executed in 2 copies of the same DLL) which will cause problem in updates. How does this apply to CSLA ? (I am sorry if I did not use the correct terms here, and I hope the point is clear)

3. Over time, we will be developing several Reusable Objects in Library Projects like that of the PTracker, which will be eventually a DLL File, right ? And as they are growing, we then have to group related BOs in separate DLLs to make it easier to manage and track. When there are so many DLLs and different versions for each, I think it cause something called DLL Hell !! Since there will be different versions of each DLL, complex project dependencies, and there will be a possibility that some projects will break due to deploying a new DLL version, which may require a recompile of the affected projects. I know this has nothing to do with CSLA, but I appreciate your input on how to avoid such problems.

4. In general, is it correct to say that we must use Web Services to expose the BO functionality to the consumers of the web services, and that we must avoid using direct reference to DLLs to avoid the threading problems and version contorl issue ?

I am not very much comfortable with the idea of Using Web Services instead of DLL References. I think we should use Web Services only when there is a real value for such approach.

Your feedback will be greatly appreciated.

Regards ...

Tarek.

Ok, I will try to be more focused now. I am preparing for a presentation tomorrow about CSLA.NET and appreciate your help.

I have already developed several Business Objects, for proof of concept, in DLLs using CSLA.NET Framework and used them in several other applications, and enabled both Integrated Windows Authentication and Forms Authentication.

I have some doubt about the multi-threading issue and the relationship with Web Services, DLLs and CSLA.NET. 

I have the following questions in that regards:

1. By default, when you develop a Web Service, are they Thread Safe ? Or do you still have to worry about Multi-threading problems due to the nature of the web server allowing requests to run in parallel in different threads ? So that, also, when writing a Web Service, you need to worry about Multi-Threading Issue ?

2. With regards to Developing Business Objects in DLLs and deploying them to a Web Server for use by other applications with direct reference, when do you have to worry about making the DLL Thread Safe ? Is it necessary to write your DLLs to be Thread Safe ? Do you have always to reference to Thread Safe DLLs in your web applications ?

3. Is CSLA.NET DLL Thread Safe ?

Tarek.

tarekahf:

1. By default, when you develop a Web Service, are they Thread Safe ? Or do you still have to worry about Multi-threading problems due to the nature of the web server allowing requests to run in parallel in different threads ? So that, also, when writing a Web Service, you need to worry about Multi-Threading Issue ?

Generally yes. By the time your service code is running, ASP.NET has assigned you a thread for the duration of that service invocation and you'll remain on that thread unless you explicitly do something to create your own threads (or use the thread pool) - but that's no different than in any .NET code, and you'd know it if you created a thread.

Obviously many service requests may be running at the same time, but each one is on its own thread.

The only places you can get into trouble here is when using object instances that are shared across the AppDomain, because those objects could be used by multiple threads at once. And when calling static/Shared methods because those are global to the AppDomain.

Unless you go out of your way to do this, no object instances are typically accessible across the AppDomain, so this is a non-issue.

tarekahf:

2. With regards to Developing Business Objects in DLLs and deploying them to a Web Server for use by other applications with direct reference, when do you have to worry about making the DLL Thread Safe ? Is it necessary to write your DLLs to be Thread Safe ? Do you have always to reference to Thread Safe DLLs in your web applications ?

Typically you do not need to make your assemblies thread-safe - other than your static/Shared methods (because they are global to the AppDomain).

The exception would be if you intend to put any objects in a position where they'd be global to the AppDomain - then you'd have to devise a locking scheme for those objects. That is quite rare and should be avoided.

tarekahf:

3. Is CSLA.NET DLL Thread Safe ?

Tarek.

The static/Shared methods in CSLA .NET are thread-safe. Otherwise no. Like 99.9% of the .NET framework, CSLA .NET is not thread-safe.

---

Rocky

So, the bottom line, is that even when you are developing Web Services, if the logic of the Web Services is using object instances that are shared across the AppDomain, then you still need to implement some kind of locking mechanism to avoid Data Corruption during update due to Multi-threading ?


Also, this means that there is no difference in terms of Multi-threading worries between using Web Service and direct reference to DLLs in your Web Application. I mean, that if the process is using object instances that are shared across the AppDomain then using the Web Service to implement such process will not solve this problem automatically, correct ?

Tarek.

---

Rocky

OK, good news. I received the book last week, and did more work with CSLA.

I have some issue raised by my colleague about using/re-using connections.

In order to be more clear and efficient, I have created a new thread here:

http://forums.lhotka.net/forums/23322/ShowThread.aspx#23322

I hope I can get your feedback on this matter.

Tarek.