| UML | |
| Diagrams | |
| Views | |
| Patterns | |
| Categorisation of Patterns | |
| SDLC/Processes | |
| Processes | |
| Phases | |
| Project Management | |
| Estimation | |
| Requirement Elicitation | |
| Requirement Management | |
| Planning and Scheduling | |
| Risk management | |
| Config Management | |
| etc | |
| OOPS | |
| OOAD | |
| Object Modelling | |
| OOAD with UML | |
| COM/COM+ | |
| MTS | |
| Deployment and management | |
| Diff between MTS and COM+ | |
| DCOM | |
| Creation | |
| Deployment and management | |
| VB/ASP | |
| Migration techniques to .NET | |
| Interop | |
| VB - MultiThreading | |
| .NET Framework/Internals | |
| CLR | |
| Assemblies | |
| etc. | |
| C# | |
| Diff between C# and VB.NET | |
| Multithreading | |
| Web Services | |
| Security | |
| Transaction | |
| SOA | |
| Comparison between Remoring and Webservices | |
| Remoting | |
| Comparison between CORBA, RMI and COM/DCOM with Remoting | |
| Transaction | |
| Serviced Components | |
| SQL Server | |
| Usage of XML in SQL | |
| Security in SQL | |
| Performance Tuning | |
| Data Modeling | |
| Whidbey/Indigo | |
| Biztalk | |
| Speech SDK | |
| SPPS | |
| XML | |
| XPATH | |
| XSLT | |
| DTD vs Schema | |
| XSL | |
| ASP.NET | |
| State maintenance between ASP and ASP.NET | |
| Perf. Max. - all techniques |
Wednesday, June 22, 2005
Schedule
Interface or Class?
Some more info that i got on the net...
Interfaces, like classes, define a set of properties, methods, and events. But unlike classes, interfaces do not provide implementation. They are implemented by classes, and defined as separate entities from classes. Even though class inheritance allows your classes to inherit implementation from a base class, it also forces you to make most of your design decisions when the class is first published.
Abstract classes are useful when creating components because they allow you specify an invariant level of functionality in some methods, but leave the implementation of other methods until a specific implementation of that class is needed. They also version well, because if additional functionality is needed in derived classes, it can be added to the base class without breaking code.
| Interfaces vs. Abstract Classes | ||
| Feature | Interface | Abstract class |
| Multiple inheritance | A class may implement several interfaces. | A class may extend only one abstract class. |
| Default implementation | An interface cannot provide any code at all, much less default code. | An abstract class can provide complete code, default code, and/or just stubs that have to be overridden. |
| Constants | Static final constants only, can use them without qualification in classes that implement the interface. On the other paw, these unqualified names pollute the namespace. You can use them and it is not obvious where they are coming from since the qualification is optional. | Both instance and static constants are possible. Both static and instance intialiser code are also possible to compute the constants. |
| Third party convenience | An interface implementation may be added to any existing third party class. | A third party class must be rewritten to extend only from the abstract class. |
| is-a vs -able or can-do | Interfaces are often used to describe the peripheral abilities of a class, not its central identity, e.g. an Automobile class might implement the Recyclable interface, which could apply to many otherwise totally unrelated objects. | An abstract class defines the core identity of its descendants. If you defined a Dog abstract class then Damamation descendants are Dogs, they are not merely dogable. Implemented interfaces enumerate the general things a class can do, not the things a class is. |
| Plug-in | You can write a new replacement module for an interface that contains not one stick of code in common with the existing implementations. When you implement the interface, you start from scratch without any default implementation. You have to obtain your tools from other classes; nothing comes with the interface other than a few constants. This gives you freedom to implement a radically different internal design. | You must use the abstract class as-is for the code base, with all its attendant baggage, good or bad. The abstract class author has imposed structure on you. Depending on the cleverness of the author of the abstract class, this may be good or bad. Another issue that's important is what I call "heterogeneous vs. homogeneous." If implementors/subclasses are homogeneous, tend towards an abstract base class. If they are heterogeneous, use an interface. (Now all I have to do is come up with a good definition of hetero/homogeneous in this context.) If the various objects are all of-a-kind, and share a common state and behavior, then tend towards a common base class. If all they share is a set of method signatures, then tend towards an interface. |
| Homogeneity | If all the various implementations share is the method signatures, then an interface works best. | If the various implementations are all of a kind and share a common status and behavior, usually an abstract class works best. |
| Maintenance | If your client code talks only in terms of an interface, you can easily change the concrete implementation behind it, using a factory method. | Just like an interface, if your client code talks only in terms of an abstract class, you can easily change the concrete implementation behind it, using a factory method. |
| Speed | Slow, requires extra indirection to find the corresponding method in the actual class. Modern JVMs are discovering ways to reduce this speed penalty. | Fast |
| Terseness | The constant declarations in an interface are all presumed public static final, so you may leave that part out. You can't call any methods to compute the initial values of your constants. You need not declare individual methods of an interface abstract. They are all presumed so. | You can put shared code into an abstract class, where you cannot into an interface. If interfaces want to share code, you will have to write other bubblegum to arrange that. You may use methods to compute the initial values of your constants and variables, both instance and static. You must declare all the individual methods of an abstract class abstract. |
| Adding functionality | If you add a new method to an interface, you must track down all implementations of that interface in the universe and provide them with a concrete implementation of that method. | If you add a new method to an abstract class, you have the option of providing a default implementation of it. Then all existing code will continue to work without change. |
Here are some recommendations to help you to decide whether to use an interface or an abstract class to provide polymorphism for your components.
If you anticipate creating multiple versions of your component, create an abstract class. Abstract classes provide a simple and easy way to version your components. By updating the base class, all inheriting classes are automatically updated with the change. Interfaces, on the other hand, cannot be changed once created. If a new version of an interface is required, you must create a whole new interface.
If the functionality you are creating will be useful across a wide range of disparate objects, use an interface. Abstract classes should be used primarily for objects that are closely related, whereas interfaces are best suited for providing common functionality to unrelated classes.
If you are designing small, concise bits of functionality, use interfaces. If you are designing large functional units, use an abstract class.
If you want to provide common, implemented functionality among all implementations of your component, use an abstract class. Abstract classes allow you to partially implement your class, whereas interfaces contain no implementation for any members.
Soni
Structures in Detail
The struct type is suitable for representing lightweight objects such as Point, Rectangle, and Color. Although it is possible to represent a point as a class, a struct is more efficient in some scenarios. For example, if you declare an array of 1000 Point objects, you will allocate additional memory for referencing each object. In this case, the struct is less expensive.
It is an error to declare a default (parameterless) constructor for a struct. A default constructor is always provided to initialize the struct members to their default values.
It is an error to initialize an instance field in a struct.
When you create a struct object using the new operator, it gets created and the appropriate constructor is called. Unlike classes, structs can be instantiated without using the new operator. If you do not use new, the fields will remain unassigned and the object cannot be used until all of the fields are initialized.
There is no inheritance for structs as there is for classes. A struct cannot inherit from another struct or class, and it cannot be the base of a class. Structs, however, inherit from the base class Object. A struct can implement interfaces, and it does that exactly as classes do.
Unlike C++, you cannot declare a class using the keyword struct. In C#, classes and structs are semantically different. A struct is a value type, while a class is a reference type. For more information on the features of value types, see Value Types.
Unless you need reference type semantics, a class that is smaller than 16 bytes may be more efficiently handled by the system as a struct.
More info here http://msdn.microsoft.com/library/default.asp?url=/library/en-us/csref/html/vcwlkstructstutorial.asp
What is the difference between a Struct and a Class?
· The struct type is suitable for representing lightweight objects such as Point, Rectangle, and Color. Although it is possible to represent a point as a class, a struct is more efficient in some scenarios. For example, if you declare an array of 1000 Point objects, you will allocate additional memory for referencing each object. In this case, the struct is less expensive.
· When you create a struct object using the new operator, it gets created and the appropriate constructor is called. Unlike classes, structs can be instantiated without using the new operator. If you do not use new, the fields will remain unassigned and the object cannot be used until all of the fields are initialized.
· It is an error to declare a default (parameterless) constructor for a struct. A default constructor is always provided to initialize the struct members to their default values.
· It is an error to initialize an instance field in a struct.
· There is no inheritance for structs as there is for classes. A struct cannot inherit from another struct or class, and it cannot be the base of a class. Structs, however, inherit from the base class Object. A struct can implement interfaces, and it does that exactly as classes do.
· A struct is a value type, while a class is a reference type.
Also,
There is no inheritance for structs as there is for classes. A struct cannot inherit from another struct or class, and it cannot be the base of a class. Structs, however, inherit from the base class Object. A struct can implement interfaces, and it does that exactly as classes do.
Some stuff from Nasar
External Interface Files
Transactional Functions
External Outputs
External Inquiries
Make it unclear who is responsible for tasks; don't trust anyone with clear ownership, but ask several people to get the job done.
Monday, June 20, 2005
How to Share Session State
Interesting article in MSDN ...
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnaspp/html/converttoaspnet.asp
Maintaining Transactions in Web Services
If you've ever programmed MTS or COM+ components, you're probably comfortable with the idea of developing transaction-based services. A transaction can be thought of as any set of procedures (e.g., events, function calls) that collectively result in a change of state such as a success or failure. One example is a credit card processing system that authenticates a credit card number, charges the card, and triggers a fulfillment process. If any of these three steps fails (e.g., the card is declined), the transaction as a whole will fail, and each of the individual processes must be returned to its original state (e.g., cancel a fulfillment process if it has been started). All three steps are part of a transaction.
Microsoft includes support in the .NET platform for MTS or COM+ style transactions through the System.EnterpriseServices namespace. We're not going to get into the details of developing transacted services in this book; however, it is important to understand the difference between .NET-style transactions and what we'll call distributed web service transactions.
.NET transaction support is set through the TransactionOption property of the WebMethod attribute. The five possible settings for this property are:
Disabled
NotSupported
Supported
Required
RequiresNew
By default, transactions are disabled. If you decide to use .NET transactions, your web method will be able to participate only as the root object in a transaction. This means that your web method may call other transaction-enabled objects, but may not itself be called as part of a transaction started by another object. This limitation is due to the stateless nature of the HTTP protocol. As a result, the Required and RequiresNew values for TransactionOption are equivalent (and both declare a RequiresNew method that will start a new transaction). Disabled, NotSupported, and Supported all disable transactions for the web method, despite what their names imply.
Friday, June 17, 2005
Access Modifiers
http://weblogs.asp.net/cnagel/archive/2004/12/27/332733.aspx
The December version of Visual Studio 2005 / C++ now has an internal access modifier instead of using public private. This is different from my previous post. The access modifiers public protected and protected private are still the same as before:
| C++ | C# | VB | IL |
| public | public | Public | public |
| protected | protected | Protected | family |
| private | private | Private | private |
| internal | internal | Friend | assembly |
| public protected | internal protected | Protected Friend | famorassem |
| protected private | not possible | not possible | famandassem |
public public is no longer supported, too. public is good enough ;-)
A: Well, I'll certainly try. The allowed access modifiers in .NET are public, private, protected, internal, and protected internal. These keywords control the visibility of class members (and other things), defining the circumstances under which a member may be accessed—hence their collective name as access modifiers. With the exception of the last, protected internal, it's illegal to combine two access modifiers. Let's look at what each of these mean in turn when used in a .NET class.
Access modifiers illustrated
Public means just that: public and visible to everyone and everything. A public member can be accessed using an instance of a class, by a class's internal code, and by any descendants of a class. This is illustrated in Figure A.
| Figure A |
![]() |
| A public class member |
Private is also intuitively understood, meaning hidden and usable only by the class itself. No code using a class instance can successfully access a private member and neither can a descendant class, as illustrated in Figure B. Information or functionality that will not be needed or has no meaning outside of the context of a specific class should be made private.
| Figure B |
![]() |
| A private class member |
Protected members are similar to private ones in that they are accessible only by the containing class. However, protected members also may be used by a descendant class. So members that are likely to be needed by a descendant class should be marked protected, as Figure C shows.
| Figure C |
![]() |
| A protected class member |
Members marked as internal are public to the entire application but private to any outside applications. Internal is useful when you want to allow a class to be used by other applications but reserve special functionality for the application that contains the class. Figure D illustrates internal in action.
| Figure D |
![]() |
| An internal class member |
Finally, we have the only compound access modifier allowed in .NET, protected internal, which is shown in Figure E. Members marked as protected internal may be accessed only by a descendant class that's contained in the same application as its base class. You use protected internal in situations where you want to deny access to parts of a class' functionality to any descendant classes found in other applications.
| Figure E |
![]() |
| A protected internal class member |
Not limited to controlling class access
As I mentioned before, access modifiers aren't limited to use on class members but can be applied to a few other code constructs. The rules defining when modifiers may be legally assigned to a construct are dependant on the construct's container:
- Interface and enumeration members are always public and no access modifiers are needed (or allowed).
- Classes in namespaces are internal by default and may be either internal or public, while namespaces themselves are always public.
- Members of a struct are private by default and may be given public, internal, or private access modifiers.
In all cases, however, the modifier's meaning remains the same.
Thursday, June 16, 2005
"How can I avoid turning into a pointy-haired boss?"
"The pointy-haired boss is a manager who doesn't program. So the surest way to avoid becoming him is to stay a programmer. What tempts programmers to become managers are companies with old-fashioned corporate structure, where the only way to advance in salary and prestige is to go into management. So if you want to avoid becoming a PHB, avoid such companies, and work for (or start) startups.
I never had to manage anyone in our startup, even though I was the president. The other hackers were my peers, and would have given me the raspberry if I'd tried to "manage" them. We operated by consensus. And the rest of the company reported to our experienced COO, who was also more of a peer.
Why be a manager when you could be a founder or early employee at a startup?"
Inputs from Nikhilesh
Looking at this text dump of a .NET PE file, you can see that a PE file starts off with the MS-DOS/COFF header, which all Windows programs must include. Following this header, you will find the PE header that supports Windows 32-bit programs. Immediately after the PE headers, you can find the code section for this program. The raw data (RAW DATA #1) of this section stores the CLR header, as follows:
RAW DATA #1 . . . clr Header: /* CLR HEADER */ 48 cb 2.00 runtime version 207C [ 214] RVA [size] of MetaData Directory 1 flags 6000001 entry point token 0 [ 0] RVA [size] of Resources Directory 0 [ 0] RVA [size] of StrongNameSignature Directory 0 [ 0] RVA [size] of CodeManagerTable Directory 0 [ 0] RVA [size] of VTableFixups Directory 0 [ 0] RVA [size] of ExportAddressTableJumps Directory
Section contains the following imports: mscoree.dll . . . 0 _CorExeMain . . .As mentioned earlier, the CLR header holds a number of pertinent details required by the runtime, including:
Runtime version Indicates the runtime version that is required to run this program
MetaData directory Is important because it indicates the location of the metadata needed by the CLR at runtime
Entry point token Is even more important because, for a single file assembly, this is the token that signifies the entry point, such as Main( ), that the CLR executes
Below the CLR Header, note that there is an imported function called _CorExeMain, which is implemented by mscoree.dll, the core execution engine of the CLR.[2] At the time of this writing, Windows 98, 2000, and Me have an OS loader that knows how to load standard PE files. To prevent massive changes to these operating systems and still allow .NET applications to run on them, Microsoft has updated the OS loaders for all these platforms. The updated loaders know how to check for the CLR header, and, if this header exists, it executes _CorExeMain, thus not only jumpstarting the CLR but also surrendering to it. You can then guess that the CLR will call Main( ), since it can find the entry point token within the CLR header.[3]
The common language runtime can either run garbage collection concurrently on a separate thread or on the same thread as the application. Use the
A delegate is a data structure that refers to a static method or to an object instance and an instance method ofthat object.
A component container is a specialized class that acts as a means of organizing and containing components. Through a container you can track your components, communicate with them via the Site that hosts the component, and provide a means of common disposal after they are no longer needed.
Wednesday, June 15, 2005
What are ASHX Files
HTTP Handlers are nothing but software modules that handle raw HTTP requests received by ASP.NET
With .ASHX files one can easily deploy HTTP Handlers without modifying IIS metabase.
What is the maximum amount of memory any single process on Windows can address
Actually, this is essentially the same for all operating systems running on 32 bit hardware that implement Virtual memory.
The only way to increase the size of the virtual address space beyond 4 GB is by using 64 bit hardware with an operating system and application built for that hardware.
In the normal, default Windows OS configuration, 2 GB of this address space are allocated to the process's private use and the other 2 GB are allocated to shared and operating system use.
The nub of it is, that no matter how much physical RAM is in the computer,the amount of memory available in the application's private part of thevirtual address space in 32 bit Windows implementations is limited to:
1. 2 GB - without the /3GB switch - this is the normal, default maximumprivate virtual address space or
2. 3GB with the /3GB switch AND a special application modification (more details below) or 3. any physical RAM not used by the OS and other applications by modifyingthe application to use the AWE (Address Windowing Extensions) API
More on address & memory allocation:
There seems to be a lot of confusion in the industry about what's commonly called the Windows “4GB memory limit.” When talking about performance tuning and server sizing, people are quick to mention the fact that an application on a 32-bit Windows system can only access 4GB of memory. But what exactly does this mean?
By definition, a 32-bit processor uses 32 bits to refer to the location of each byte of memory. 2^32 = 4.2 billion, which means a memory address that's 32 bits long can only refer to 4.2 billion unique locations (i.e. 4 GB).
In the 32-bit Windows world, each application has its own “virtual” 4GB memory space. (This means that each application functions as if it has a flat 4GB of memory, and the system's memory manager keeps track of memory mapping, which applications are using which memory, page file management, and so on.)
This 4GB space is evenly divided into two parts, with 2GB dedicated for kernel usage, and 2GB left for application usage. Each application gets its own 2GB, but all applications have to share the same 2GB kernel space.
This can cause problems in Terminal Server environments. On Terminal Servers with a lot of users running a lot of applications, quite a bit of information from all the users has to be crammed into the shared 2GB of kernel memory. In fact, this is why no Windows 2000-based Terminal Server can support more than about 200 users—the 2GB of kernel memory gets full—even if the server has 16GB of memory and eight 3GHz processors. This is simply an architectural limitation of 32-bit Windows.
Windows 2003 is a little bit better in that it allows you to more finely tune how the 2GB kernel memory space is used. However, you still can't escape the fact that the thousands of processes from hundreds of users will all have to share the common 2GB kernel space.
Using the /3GB (for Windows 2000) or the /4GT (for Windows 2003) boot.ini switches is even worse in Terminal Server environments because those switches change the partition between the application memory space and kernel memory space. These switches gives each application 3GB of memory, which in turn only leaves 1GB for the kernel—a disaster in Terminal Server environments!
People who are unfamiliar with the real meaning behind the 4GB Windows memory limit often point out that certain versions of Windows (such as Enterprise or Datacenter editions) can actually support more than 4GB of physical memory. However, adding more than 4GB of physical memory to a server still doesn't change the fact that it's a 32-bit processor accessing a 32-bit memory space. Even when more than 4GB of memory is present, each process still has the normal 2GB virtual address space, and the kernel address space is still 2GB, just as on a normal non-PAE system.
However, systems booted /PAE can support up to 64GB physical memory. A 32-bit process can "use" large amounts of memory via AWE (address windowing extension) functions. This means that they must map views of the physical memory they allocate into their 2GB virtual address space. Essentially, they can only use 2GB of memory at a time.




