SQL injection is a very serious threat in the software and web industry as of current stats. It is also increasingly hitting databases like anything. The process allows miscreants to hack into your system through your web interface. However, the same tools could be used by security pros to find out SQL injection vulnerabilities in the system.
If you have an image field in the table, you have to save the image as an array of bytes:
using System.Drawing; using System.IO; using System.Drawing.Imaging;
public byte[] ImageToByteArray(Image imageIn) { var ms = new MemoryStream(); imageIn.Save(ms, ImageFormat.Png); return ms.ToArray(); }
public Image ByteArrayToImage(byte[] byteArrayIn) { var ms = new MemoryStream(byteArrayIn); var returnImage = Image.FromStream(ms); return returnImage; }
N-Tier architecture is an industry-proved software architecture model, suitable to support enterprise-level client/server applications by resolving issues like scalability, security, fault tolerance and etc. .NET has many tools and features, but .NET doesn’t have pre-defined ways to guard how to implement N-Tier architecture. Therefore, in order to achieve good design and implementation of N-Tier architecture in .NET, understanding fully its concepts is very important. However, many of us may hear, read or use N-Tier architecture for many years but still misunderstand its concepts more or less. This article tries to clarify many basic concepts in N-Tier architecture from all aspects, and also provide some practical tips. The tips in this article are based on the assumption that a team has a full control over all layers of the N-Tier architecture.
The first big difference between the Entity Framework and LINQ to SQL is that the EF has a full provider model which means that as providers come online (and there are several in beta now and many which have committed to release within 3 months of the EF RTM), you will be able to use the EF against not only SQL Server and SQL CE but also Oracle, DB2, Informix, MySQL, Postgres, etc.
Next there is the fact that LINQ to SQL provides very limited mapping capabilities. For the most part L2S classes must be one-to-one with the database (with the exception of one form of inheritance where there is a single table for all of the entity types in a hierarchy and a discriminator column which indicates which type a particular row represents). In the case of the EF, there is a client-side view engine which can transform queries and updates made to the conceptual model into equivalent operations against the database. The mapping system will produce those views for a variety of transformations.
All these three approaches define how much control you want on your Entity Framework code. Entity Framework is an OR mapper, it generates a lot of code, it creates your middle tier (Entity), and Data Access layer (Context).
But a lot of times you want to enjoy the benefits of both worlds, you want the auto-generation part to minimize your development time and you want control on the code so that you can maintain code quality.
Below is the difference table which defines each of the approaches. In simple Entity Framework, everything is auto generated and so you need the EDMX XML file as well. POCO is semi-automatic so you have full control on the entity classes but then the context classes are still generated by the EDMX file.
In Code First, you have complete control on how you can create the entity and context classes. Because you are going to manually create these classes, you do not have dependency on the EDMX XML file. Below is a simple table which shows the cross comparison.
| EDMX | Entity | Context | |
| Simple entity framework | Needed | Auto | Auto |
| POCO approach | Needed | Manual | Auto |
| Code First | Not Needed | Manual | Manual |
By default EF has lazy loading behavior. Due to this default behavior if you are loading a large number of records and especially if they have foreign key relationships, you can have performance issues. So you need to be cautious if you really need lazy loading behavior for all scenarios. For better performance, disable lazy loading when you are loading a large number of records or use stored procedures.
Lazy loading is a concept where we load objects on demand rather than loading everything in one go. Consider a situation where you have 1 to many relationships between the Customer and Address objects. Now let’s say you are browsing the customer data but you do not want address data to be loaded at that moment. But the time you start accessing the address object you would like to load address data from the database.
Entity Framework has lazy loading behavior by default enabled. For instance, consider the below code. When we are doing a foreach on the Customer object, the Address object is not loaded. But the time you start doing foreach on the address collection, the Address object is loaded from SQL Server by firing SQL queries.
So in simple words, it will fire a separate query for each address record of the customer, which is definitely not good for a large number of records.
MyEntities context = new MyEntities(); var Customers = context.Customers.ToList(); foreach (Customercust in Customers) // In this line no address object loaded { foreach(Address add in cust.Addresses){} // Address object is loaded here }
CSDL, SSDL and MSL are actually XML files.
“Pluralize” and “Singularize” give meaningful naming conventions to objects. In simple words it says do you want to represent your objects with the below naming convention:
Find the following Excel file which contains all public details about world countries, you will get:
Click Countries to download the file or get it from my dropbox.
More Coding 