Pages

Tuesday, October 25, 2022

What is a proxy server

A proxy server sometimes referred to as a forward proxy, is a server that routes traffic between the client(s) and another system, usually external to the network. Doing so can regulate traffic according to preset policies, convert and mask client IP addresses, enforce security protocols, and block unknown traffic.


What are forward and reverse proxies

Professional businesses, such as banks, insurance companies, and government agencies often put office computers used by company employees on a single, isolated private network. This isolation protects corporate computers from outside attacks. It also restricts the ability of users to nefariously move data and files out of the protected subnet.

However, it's nearly impossible for employees in a modern workplace to perform their jobs without some level of access to the internet. This is where the forward proxy comes in.

A forward proxy accepts connections from computers on a private network and forwards those requests to the public internet. It is the single point of exit for subnet users who want to access resources outside of their private network.

As the name implies, a reverse proxy is the opposite of a forward proxy. The reverse proxy acts as a single point of entry for external systems to access resources on a private subnet.

In an enterprise architecture, a reverse proxy acts as the public access point for users to access data and information that is stored on servers that reside in a private, isolated subnet. 

Friday, May 22, 2020

The SOLID Object Oriented Programming(OOPS) Principles

SOLID Principles

What does it take to be an Object-Oriented Programmer? There was a time where I believed all that meant was that you worked with a language such as C#, C++, or Java. However, the more I get acquainted with newer technologies, the more I realize that there is a set of fundamentals core to the title. And really, these fundamentals are about architecting the best, most update-able, scalable systems. Just yesterday while diving into DataObjects.NET, I was greeted by Domain-Driven Design(DDD)-- a popular architectural abstraction. It motivated me to think about the basics, which is the purpose of this article.

The S.O.L.I.D. Principles of Class Design

The SOLID Principals seem to be the least common denominator of creating great classes; even before Design Patterns. I recommend taking some time to really think about each of them and how you can apply them. Let's dive in, one by one.

The Single Responsibility Principle

There should never be more than one reason for a class to change. Basically, this means that your classes should exist for one purpose only. For example, let's say you are creating a class to represent a SalesOrder. You would not want that class to save to the database, as well as export an XML-based receipt. Why? Well if later on down the road, you want to change database type (or if you want to change your XML schema), you're allowing one responsibility's changes to possibly alter another. Responsibility is the heart of this principle, so to rephrase there should never be more than one responsibility per class.

The Open Closed Principle

Software entities (classes, modules, functions, etc.) should be open for extension but closed for modification. At first, this seems to be contradictory: how can you make an object behave differently without modifying it? The answer: by using abstractions, or by placing behavior(responsibility) in derivative classes. In other words, by creating base classes with override-able functions, we are able to create new classes that do the same thing differently without changing the base functionality. Further, if properties of the abstracted class need to be compared or organized together, another abstraction should handle this. This is the basis of the "keep all object variables private" argument.

The Liskov Substitution Principle

Functions that use pointers or references to base classes must be able to use objects of derived classes without knowing it. In other words, if you are calling a method defined at a base class upon an abstracted class, the function must be implemented properly on the subtype class. Or, "when using an object through its base class interface, [the] derived object must not expect such users to obey preconditions that are stronger than those required by the base class." The ever-popular illustration of this is the square-rectangle example. Turns out a square is not a rectangle, at least behavior-wise.

The Dependency Inversion Principle

Depend on abstractions, not on concretions or High-level modules should not depend upon low-level modules. Both should depend upon abstractions. Abstractions should not depend upon details. Details should depend upon abstractions. (I like the first explanation the best.) This is very closely related to the open-closed principle we discussed earlier. By passing dependencies (such as connectors to devices, storage) to classes as abstractions, you remove the need to program dependency specific. Here's an example: an Employee the class that needs to be able to be persisted to XML and a database. If we placed ToXML() and ToDB() functions in the class, we'd be violating the single responsibility principle. If we created a function that took a value that represented whether to print to XML or to DB, we'd be hard-coding a set of devices and thus be violating the open-closed principle. The best way to do this would be to:
 
   Create an abstract class (named DataWriter, perhaps) that can be inherited from for XML (XMLDataWriter) or DB (DbDataWriter) Saving, and then
CCreate a class (named EmployeeWriter) that would expose an Output(DataWriter saveMethod) that accepts a dependency as an argument. See how the Output method is dependent upon the abstractions just as the output types are? The dependencies have been inverted. Now we can create new types of ways forEmployee data to be written, perhaps via HTTP/HTTPS by creating abstractions, and without modifying any of our previous code! No rigidity--the desired outcome.

The Interface Segregation Principle

Clients should not be forced to depend upon interfaces that they do not use. My favorite version of this is written as "when a client depends upon a class that contains interfaces that the client does not use, but that other clients do use, then that client will be affected by the changes that those other clients force upon the class." Kinda sounds like the inheritance specific single responsibility principle.

Sources

Wednesday, May 20, 2020

Insert bulk record in sql server

Often, we have a need to generate and insert many rows into a SQL Server Table. For example, for testing purposes or performance tuning. It might be useful to imitate production volume in the testing environment or to check how our query behave when challenged with millions of rows.

CREATE
TABLE dbo.Table1 (
        id int PRIMARY KEY
        ,number int
        ,name nvarchar(10)
);

Procedure:
IF OBJECT_ID ('dbo.addRows', 'P') IS NOT NULL
        DROP PROCEDURE dbo.addRows;
GO
CREATE PROCEDURE dbo.addRows 
        @rowsNumber int
AS
BEGIN
        SET NOCOUNT ON
        -- start point for adding rows
        DECLARE @id INT = ISNULL((SELECT MAX(id) FROM dbo.Table1)+1, 1)
        DECLARE @iteration INT = 0
        WHILE @iteration < @rowsNumber
                BEGIN
                       --get a random int from 0 to 100
                       DECLARE @number INT = CAST(RAND()*100 AS INT)
                       -- generate random nvarchar
                       -- get a random nvarchar ascii char 65 to 128
                       DECLARE @name NVARCHAR(10) = N'' --empty string for start
                       DECLARE @length INT = CAST(RAND() * 10 AS INT) --random length of nvarchar
                       WHILE @length <> 0 --in loop we will randomize chars till the last one
                               BEGIN
                                       SELECT @name = @name + CHAR(CAST(RAND() * 63 + 65 as INT))
                                       SET @length = @length - 1 --next iteration
                               END
                       --insert data
                       INSERT INTO dbo.Table1 (id, number, name)
                       VALUES (@id, @number, @name)
                       SET @iteration += 1
                       SET @id += 1
               END
        SET NOCOUNT OFF
END

Using this procedure will enable us to add the requested number of random rows.
Sample:
EXEC dbo.addRows 1000 --elapsed time ~0.11
EXEC dbo.addRows 10000 --elapsed time ~1.1
EXEC dbo.addRows 100000 --elapsed time ~9.64
EXEC dbo.addRows 1000000 --elapsed time ~2:11.88