The main benefit of a POCO is that you can pass it to a class, library or assembly that doesn’t need to know anything about Entity Framework to do its job.
Remember the Single Responsibility Principle – your DAL should know about EF, but your Domain should not, and neither should your presentation layer, because EF deals with data access and those layers do not. Passing EF generated class objects up to those layers generally means you need to make those layers aware of EF, breaking the SRP and making it harder to unit test those layers in isolation.
In more complex applications, you will want to split the logic up into separate concerns – data access, business logic, presentation (and perhaps a lot more).
As entity framework deals with data access, it resides in the data access layer – here, you will see little difference between POCOs and EF generated classes. This is fine, because this layer already knows about Entity Framework.
However, you may want to pass data up to the business logic layer – if you do this with EF generated classes, then your business logic layer must also know about Entity Framework because the EF classes rely on a lot of things EF provides specially. What this does is remove the isolation that your business logic layer should have – you need this isolation so you can unit test it correctly by injecting known data into the class from a fake data access layer, which is incredibly hard to do if you let the business logic layer know about EF.
With unit testing, you should be testing the layers functionality, not the functionality of third party libraries – but with EF you end up testing a lot of EF’s functionality, or your own functionality which relies very heavily on that of EF’s. This isn’t good, and it can mask errors or issues.
Removing the business logics dependency on EF generated classes also allows you to move the layer to as remote a location as you like from the data access layer – you can even stick it behind a web service and it would be completely happy. But you can only do this with POCOs, you cannot do this with EF generated classes.
POCO’s really come into their own in large, complex multi layered applications – if you aren’t layering your app, then you won’t see a whole load of benefits.
A common table expression (CTE) can be thought of as a temporary result set that is defined within the execution scope of a single SELECT, INSERT, UPDATE, DELETE, or CREATE VIEW statement. A CTE is similar to a derived table in that it is not stored as an object and lasts only for the duration of the query. Unlike a derived table, a CTE can be self-referencing and can be referenced multiple times in the same query.
A CTE can be used to:
- Create a recursive query. For more information, see Recursive Queries Using Common Table Expressions.
- Substitute for a view when the general use of a view is not required; that is, you do not have to store the definition in metadata.
- Enable grouping by a column that is derived from a scalar subselect, or a function that is either not deterministic or has external access.
- Reference the resulting table multiple times in the same statement.
Using a CTE offers the advantages of improved readability and ease in maintenance of complex queries. The query can be divided into separate, simple, logical building blocks. These simple blocks can then be used to build more complex, interim CTEs until the final result set is generated.
CTEs can be defined in user-defined routines, such as functions, stored procedures, triggers, or views.
SQL CTE Example
The CTE should be used directly by the query following it since it will be deleted after that, so you can’t define a cte and use it after 2 or 3 queries since an error will be generated telling you that the table ctetable1 (for example) doesn’t exist.
For Recursive Queries Using Common Table Expressions check this link:
Checking string emptiness
Checking the length of the string (if str.length = 0) is faster than (if str = “”) in three times, so off course it is more likely to use.
StringBuilder VS String
String builder is faster than strings when the number concatenations exceeded 3, but if it is less than that than normal string is a little bit faster.
Usually we compare strings in the normal way which is (if str1 = str2 then…) but It is faster to compare strings in his way:
Dim str1 As String = “”
Dim str2 As String = “”
If str1.Equals(str2) Then
‘ here comes your code