Introduction to Components Components mean different things to different people. To me, a component is code that's compiled into a dynamic link library (DLL) that can be shared across applications. Even if the DLL isn't shared across applications, it provides me with the ability to encapsulate my application logic into specific parts. I might have a data access component, a utility component, and a security component. By splitting apart the core functionality of my applications in separate DLLs, I can modify the behavior of the application without modifying the code in the user interface.This type of development is especially effective in traditional Active Server Pages (ASP) applications. Because ASP is script, and not compiled, you could achieve performance gains by putting code in DLLs and having the ASP application call methods in the DLLs. Doing so avoids the overhead of Internet Information Server (IIS) having to process the thousands of lines of script code that would have existed inside the ASP page itself.Writing components is done using the ActiveX DLL template in Visual Basic 6. By implementing methods, properties, and events in class modules, you can compile your code into a component object model (COM) DLL and use it anywhere you need it. You create reusable objects, as long as the DLL is registered correctly on that machine that's attempting to consume it.In .NET, the concept of writing components is the same, but it's taken to the next level. Because the core of .NET is based on inheritance, you can inherit from specific classes to give your component the functionality you want. Depending on what type of component you need to write, you can inherit from different base classes to expose functionality to your component that you would have had to write if you were using Visual Basic 6. Being Day 1, "Introduction to the Microsoft .NET Framework," that after code has been just-in-time (JIT) compiled, it's in the machine language for the specific processor it's running on. That begs the question, "Why write components separate from my ASP.NET code if it's all compiled anyway?" The short answer is you don't have to. After code is compiled, it can run no faster, so your code being compiled in a component or a code-behind makes no performance difference. The biggest reason to write components is to separate the business logic and the data logic from the user interface logic. This makes maintaining applications easier and provides a clear division of labor for team development. Plus, by separating the code from the content, you can reuse your components in other applications. So, in my opinion, you should separate your implementation code from user interface code as much as possible. |
|