Friday, December 30, 2011

Domain Driven Design - Explaining in your own language

Recently I have presented in a session at my office on Domain Driven Design. In the session I tried to explain different concepts of Domain Driven Design in a very simplistic manner.

Here is the link:
http://www.slideshare.net/mahmud05/domain-driven-design-10599355

Software Requirement Analysis and Thinking Process towards a good Architecture

Recently I have presented in a session in my office on thinking process towards a good architecture through proper analysis of the requirement. Here is the link of the slides:

http://www.slideshare.net/mahmud05/software-requirement-analysis-and-thinking-process-towards-a-good-architecture

Friday, October 28, 2011

Dynamically inject values to object using reflection in type safe manner - DataAccess Layer Map Function


I am sure most of us, who are not using any ORM, have written methods like the following number of times in our life. This is the function that maps the resultant DataGrid with the equivalent object.

protected override UserSession Map(System.Data.IDataReader reader)
{
  var userSession = new UserSession()
{
  ID = NullHandler.GetLong(reader, "ID"),
 Browser = NullHandler.GetString(reader, "Browser"),
 BrowserVersion = NullHandler.GetString(reader, "BrowserVersion"),
 IpAddress = NullHandler.GetString(reader, "IpAddress"),
 UserAgent = NullHandler.GetString(reader, "UserAgent"),
 SiteId = NullHandler.GetInt32(reader, "SiteId"),
 StartTimeStamp = NullHandler.GetDateTime(reader, "StartTimeStamp"),
 EndTimeStamp = NullHandler.GetDateTime(reader, "EndTimeStamp"),
 UserName = NullHandler.GetString(reader, "UserName"),
 IsActive = NullHandler.GetBoolean(reader, "IsActive"),
 IsDeleted = NullHandler.GetBoolean(reader, "IsDeleted"),
 CreatedBy = NullHandler.GetString(reader, "CreatedBy"),
 CreatedByDateTime = NullHandler.GetDateTime(reader, "CreateByDateTime"),
 LastModifiedBy = NullHandler.GetString(reader, "LastModifiedBy"),
 LastModifiedByDateTime = NullHandler.GetDateTime(reader, "LastModifiedByDateTime"),
 SystemModstamp = NullHandler.GetDateTime(reader, "SystemModstamp")
};


  return userSession;
}

What most of us do to write this function is, we copy one similar function from some other class then, make changes to the function based on our entity. Whatever time this function takes to write, I am sure we all feel bore to do that.

Most of the time,  we always override this map function in every DataAccess class even though this function has a similar pattern of implementatiion.

That is why, I have tried to write a default implementation of this Map function in BaseDataAccess to save our time:

/// Maps and sets the Entity Model from the specified reader.protected virtual TEntity Map(IDataReader reader)
{
var entity = Activator.CreateInstance();
  foreach (PropertyInfo info in entity.GetType().GetProperties()
.Where(p => p.GetCustomAttributes(true)
 .FirstOrDefault(at => at.GetType() == typeof (ParameterExclusionAttribute)) == null)
)
  {
object data = NullHandler.GetDataForColumn(info.Name, reader);
if (info.CanRead)
{
 Type propertyType = info.PropertyType;
 Type underlyingType = Nullable.GetUnderlyingType(propertyType);


 if(data==null || data == DBNull.Value)
 {
if (propertyType == typeof(String))
{
 data = string.Empty;
}
else
{
 data = propertyType.IsValueType ? Activator.CreateInstance(propertyType) : null;
}                                
 }
 else
 {
data = Convert.ChangeType(
 data, underlyingType ?? propertyType);                                
 }
 info.SetValue(entity, data, null);
}                    
  }
return entity;
}

This Map function in BaseDataAccess will automatically map the resultant datareader with your entity. So, it will save our time and energy and we will not need to write this Map functions in every DAL classe anymore. BUT, There is a constraint. To use this default implementation we must follow the practice of “Convention over Configuration”. To  use this, we must have the name of the object’s properties and the database table’s column name same.  I believe this is a very standard practice and we all follow this. Who are not following this yet, should start doing so from now.

Monday, October 10, 2011

SharePoint Server 2010 - Deployment conflicts - Could not delete file

Here is what I did:
1. I created one module in VS 2010.
2. I added one master page inside the module
3. I modified the Elements.xml file of the module as:

4. Then I created a feature for this module.
5. My target was to deploy the module so that I can use my custom master page for my site.

Here is what I Got when trying to deploy from VS 2010:
1. When I 1st time deployed the solution it worked fine. and I found my new master page in place.
2. When I did little modification into the master page and tried to deploy again, I got the following error:
3. I was digging with the problem. I found that if I do not use the master page from any site, I can deploy the solution. So, One solution could be before each deployment change the master page of the site, then deploy and then get the master page selected back for the site. 
4. But the solution was not acceptable and comfortable. So, I continued digging the issue and finally came to a solution.
Here is what I did to solve the issue:
1st of all it seems the issue was caused by a possible bug of VS 2010. If you go to the property window of the specific folder you will see Deployment Conflict Resolution is set to automatic. Which was the expected value for me.

 As it was not working, I changed the value to prompt. Then, I started to get prompt about the conflict. If I click the button to resolve the conflict automatically, I found the issue is solved and it worked.

Still, to me, the solution was not 100% acceptable as getting a prompt in every deploy was frustrating. Later, I change the value to "None". It was not an acceptable value at all to my consideration. but surprisingly it solved the problem. So, ISSUE RESOLVED! 

In Summary: 
1. Right click the folder/list of your concern.
2. Go to properties
3. Set Deployment conflict resolution to "None".

4. Deploy and have fun with SharePoint :)

SharePoint Server 2010 - Error occured in deployment step 'retract solution' cannot start service SPUserCodeV4 on computer

I was creating a simple feature in a SharePoint 2010 server project. While I was trying to deploy it using visual studio 2010 I got the following error:
error occured in deployment step 'retract solution' cannot start service SPUserCodeV4 on
computer ....
Later I found the solution of this issue. Here is what I had to do:


1. Go to Central Administration
2. Open "System Settings"
3. Open "Manage services on server"
4. Locate the service “Microsoft SharePoint Foundation User Code Service”
5. Start the service  “Microsoft SharePoint Foundation User Code Service”

Wednesday, October 5, 2011

Sharepoint Server 2010 - Learning Steps and Resources


When I have learned that, my new project is going to be a sharepoint 2010 project, I got excited. The reason is, I have been in software development for more than 7 years and gone through different technologies, but sharepoint is really a cutting edge item that I never looked into. However, when I started my learning, I discovered, there are lot of articles, books, tutorials, videos and other resources available for SharePoint over WWW both from Microsoft and 3rd parties. In first few days, I found my self in middle of a big ocean and was searching to reach some kind of land. Gradually, I started to get familiarize with Sharepoint and I felt, I should share the learning steps and resources with the community so that, new guys no more needs to swim across Sharepoint ocean in WWW. 
Here, I have sorted out the questions that came into my mind when I started learning SharePoint initially and I have tried to provide resources that were helpful to answer my questions.

Q/A:
1.     What are the minimum hardware requirements for a development computer to develop in SharePoint? What are the requirements for production machines?
2.     What is the history of SharePoint? How did this evolve?
3.     What are the options and versions of SharePoint available and what are their capabilities?
What are the limitations of SharePoint Foundation 2010 comparing with SharePoint Server 2010?
4.     What are the features of SharePoint server 2010?
5.     How should be the development environment for SharePoint development in a team?
6.     What are the tools available to develop in SharePoint 2010?
7.     How is the Architecture of share point?
8.     How does authentication managed in SharePoint 2010?
a.     Claim based authentication
b.    Forms based authentication
9.     What are Business connectivity services in SharePoint? What it can do?
10.  How to manage deployment of SharePoint project?
11.  How to manage source control of a SharePoint project?
12.  How to use Unit tests for a SharePoint project?

Here are some How To’s for SharePoint Server 2010 as I went through learning phase.

How To’s:

1.       Creating SharePoint 2010 Web Parts That Can Read and Write Data to External Data 
2.      Configuring a profile sync connection to an external sql database
3.      Getting Started with SharePoint 2010 Development Tools in Visual Studio 2010
4.      Basic SharePoint 2010 Feature Development
5.      Introducing SharePoint Designer 2010
6.      SharePoint 2010 master page as feature
7.      Enterprize Search
8.      Taxonomy/Managed Metadata
9.      Using LINQ to SharePoint in SharePoint 2010
10.    LINQ to SharePoint using Extension methods with Lambda expressions. (Codeplex solution)
11.    Use Dotnet Client Object Model in SharePoint 2010
12.    Use Javascript Client Object Model in SharePoint 2010
13.    Create a list, columns and view programmatically

1.    


And this is great tool from Microsoft to research, learn and implement the best practices in SharePoint 2010 server development and deployment:
Learning Tools:
1.       Developing Applications for SharePoint 2010

Friday, March 11, 2011

BEST PRACTICES FOR WRITING BETTER SQL


Background:
The performance of SQL query that we write for different projects is a very crucial issue for us. In many cases we have to perform time consuming optimization work to come out from this performance related problems. Surprisingly, most of the time we succeed to improve our poor SQLs to an optimum level of acceptance. In my experience, when we worked on these optimizations we found, if we could follow some very simple practices of writing SQL and were a little more aware of performance, this issue could have been avoided from the beginning. So, our goal should be to write the best possible SQLs in our first attempt so that we do not need to spend our expensive time to optimize them later.
Here I am trying to share some of the experiences I gained while working in different optimization tasks.
Analyzing SQL:
Analyzing the performance of your SQL at best you can in parallel to the development is very important. If you perform this analysis for every query/operational statement you write before moving to the next query/operational statement of the procedure you can easily trace where the performance is suffering. You should always remember, the time that your procedure takes is the summation of all the query and operational statement that executes inside it. Normally if any of your queries takes more than 0-20 millisecond, you must revise the SQL to see if there is better way to write it.
Here I am providing one utility function that I have written and used in some of my optimization work and found very helpful for tracing the execution time of any SQL in millisecond level:
CREATE FUNCTION [dbo].[GetCurrentTime]()
RETURNS varchar(100)
AS
BEGIN
DECLARE @time varchar(100)
SET @time = (CAST(DATEPART(mi,getDate()) ASvarchar(50)) + ' Min: ' +CAST(DATEPART(ss,getDate()) AS varchar(50)) + ' Sec: ' + CAST(DATEPART(ms,getDate()) ASvarchar(50)) + ' Ms')
RETURN @time
END
You can use the above function in the following way:
DECLARE @time varchar(100)
SET @time = ( dbo.GetCurrentTime())
print 'Current Time: ' + @time
PRINT '----------------------------------------------------------'
--Here write your sql statement.
PRINT '----------------------------------------------------------'
SET @time = ( dbo.GetCurrentTime())
print 'Current Time: ' + @time
This will print the execution start time and execution end time of your SQL in milliseconds while you run the SQL for tracing in the query analyzer. So, from this result you can easily find the time your procedure is taking to execute. Instead of using this function you can utilize SQL profiler as well. But this function will help you get the timing with in the same window that you are working in. However, SQL profiler provides few more information about your query that also might help you to analyze the performance of the SQL. So, do not keep it away from you.
Best Practices:
1. Database Design:
The Design of your database is very important for writing best performance SQL. You must ensure the database is normalized to some extent. Be sure that normalization does not affect the performance of your database. For large and frequently accessed database normalization can cause performance downfall in some cases. So, you must analyze the design carefully to decide the level of normalization you require.
2. Writing Trigger:
In many scenarios we write triggers on database tables. In one of my optimization task I found few triggers extremely slow in performance due to some conceptual lacking of the developer. So here I want to share my experience about those triggers.
Before writing a trigger we need to understand what trigger is and how exactly it works. Trigger is actually a procedure that runs in response of an event fired due to performing some operations on database tables. The events could be insert, update or delete. Now, the question is how database handles the execution of a trigger when it fires? If you write a trigger for insert operation on a table, after firing the trigger, it creates a table named “INSERTED” in the memory. Then it performs the insert operation and after that the statements inside the trigger executes. We can query the “INSERTED” table to manipulate with the inserted row/s from the trigger. Similarly if you write a trigger for delete operation on a table, it creates a table in memory named “DELETED” and then deletes the row. More importantly you must understand how an update trigger works. After firing an update trigger it works in the following sequence:
  1. All constraints are enforced.
  2. All declarative referential integrity (DRI) constraints are enforced (via foreign keys).
  3. The inserted and deleted tables are created for use within the trigger.
  4. The triggering action (in this case the UPDATE statement) is executed.
  5. The AFTER UPDATE trigger executes.
From the above steps you can see that no table called “UPDATED” is created. Actually on database no operation called update executes. Internally it actually deletes the row to be updated and then inserts the row with the new updated value. So, from an update trigger we can access both INSERTED and DELETED table though directly we may not execute any insert or delete operation. This is a very important concept for us. Here I am providing the mistakes you may make if you are not clear on this.
Consider the following trigger:
CREATE TRIGGER TriggerName ON YourTableName
AFTER UPDATE ,INSERT , DELETE
AS
if(exists(select Contact_Id from inserted whereContact_id is not null))
begin
--Do your operation
end
if(exists(select Contact_Id from deleted whereContact_id is not null))
begin
--Do your operation
end
Here the developer wrote the trigger for all the events on the table and expecting to do some operation if Contact_ID is inserted, deleted or updated in to the table. Now note carefully the mistakes that the developer did in this trigger. For example an operation is executed on the table which updates some other field other than Contact_ID. Now if Contact_ID is a not null column of the table we will never get null from INSERTED and the DELETED table. So, here even though Contact_ID is not updated the operation of the triggers will execute. It is not finished yet. It has more problems as well. The Developer wrote the 2ndif condition assuming that DELETED table will be created only when trigger fires for any Delete operation on the table. But you see, as a matter of fact this table is also available when the trigger fires for update operation. The situation will be the worst if the developer thinks the first if statement will be successful for INSERT and UPDATE operation and 2nd if statement will be successful for DELETE operation. Only In that case he might write the same instructions to execute both if statements. This will in turn execute the same operation twice. Doesn’t it sound very silly and surprising? Yes. But if you are not careful these mistakes can happen anytime and can take you to hell from the heaven you are currently in.
So, while writing a trigger keep an eye on the following points:
i. If you write a single trigger for multiple event, be very careful to ensure that your trigger does not execute for unwanted events.
ii. When writing update trigger always check if your desired column is updated by using IF UPDATE(ColumnName).
iii. Be very careful in querying INSERTED and DELETED table.
iv. Try to avoid cursor from the trigger.
v. Ensure that your trigger is not creating any deadlock/Infinite loop on your database.
3. Using INNER JOIN Vs WHERE clause:
This is true that from performance perspective a query written using WHERE clause and a query written using INNER JOIN do not have any difference. If we watch the execution plan of both the query we will see it actually executes in the same way. Then what actually you should use for joining 2 tables? You must always use INNER JOIN not WHERE clause. That means you have to ensure that if you have n number of tables in your query you must have at least n-1 number of joins. Why? Well, there are several reasons:
i. INNER JOIN makes your query more readable and logical looking.
ii. It makes your query more manageable.
iii. It separates the joining condition from filtering condition of your query.
iv. It will make your life easier when you have complex queries with several joins.
v. It will minimize the possibility of error in the result of the query
vi. Above all, trust me, it will reduce the time for writing the query.
4. Index Creation
Creating necessary indexes on your database is very important. In one of my optimization work I found just creating 2 indexes on a table gives my query 50% performance boost. Determining the correct indexing policies is very crucial for your database. You must remember that proper indexing is good for your database performance but on the other hand creating indexes unwisely can affect your database performance significantly. Unnecessary index creates overheads on database server memory and also could result extremely slow (Sometimes never ending) query performance. So what are the basics you should follow to consider creating index? Here are some key features that makes database columns to be candidate for indexing:
i. Ensure that you have at least one primary key in your table. Sql Server automatically indexes the primary keys.
ii. All foreign keys are good candidates to be indexed.
iii. Columns on which ordering operation is done very frequently are very good candidate for indexing.
iv. Columns on which a large table is filtered or joined in different queries are also good candidates for indexing.
Remember for creating index no rule can be considered as Bible. You should always analyze the database and go for extensive testing to find if an index is helpful for your database. For better understanding you may like to do further study on it.
5. Using Temporary Table
In many stored procedures I have found we have used temporary tables without giving much thought on it. We should know that temporary tables are created in the tempdb and and any insert/update/delete operation or queering from temporary table has extra overhead as you have to access a table of out side of your database internally. So, try to avoid temporary table as long as you can. If you see there is no alternative of using this, you must define the table with CREATE TABLE statement with proper primary/unique key constraints and if required create indexes on it. This perhaps can improve the performance of your query.
6. Using Table Variable
In SQL server we have an alternative of temporary table called Table variable. Perhaps many of you are not aware of this. Table variable is created in memory and performs lot better than temporary table reducing the overhead on database. But If you need a table that will contain huge amount of data temporary table actually could be better for you. Because you cannot create index on Table variable but in temporary table you can.
7. Avoid Using Dynamic SQL:
Think twice before writing any dynamic SQL in your procedure. If possible try to avoid this. Here are few drawbacks of writing dynamic SQL:
i. It does not allow your stored procedure to be pre compiled and thus affects performance.
ii. It makes your query less manageable.
iii. It makes your query less readable.
iv. It can open your procedure for possible XSS attack.
In many cases we can avoid writing dynamic SQL. For example, in most of the cases you write dynamic SQL for using variable with TOP key word. Yes you needed to do it in SQL 2000. But now in SQL 2005 it can be achieved without dynamic query. Just put a bracket around your variable with the TOP key word and it will work. Example: SELECT TOP (@size) marks FROM result
So, the key point is you will not write dynamic query as long as it can be avoided.
8. Using Like Operator:
Filtering your query using Like key word could be very slow in performance if you query on a table with huge amount of data specially if you have other joins with this filtering criteria. So when you need to achieve the functionality of “Like” operator on a high volume table consider using Full Text query instead of that.
9. Using OR in your WHERE condition:
Be very careful in using OR in your filtering criteria’s. It can make your query significantly slow. In one of my optimization work I got a query of the following format:
FROM
Action
,Relationship rel
where
(Action.GROUP_ID=@GroupID
OR (rel.GROUP_ID=@GroupID
AND rel.CONTACT_ID= Action.CONTACT_ID
)
)
A query written in above format was taking almost 7-8 sec to execute. I just spited the query in 2 queries and united them using UNION operator. It improved the query to be executed just in few milliseconds. You see the significant performance gain you can achieve in this way? So always try to utilize UNION instead of using OR filtering criteria.
10. Use of cursor:
Probably cursor is the most dangerous tool exists in SQL that can kill the performance of your procedure. Remember in most of the cases cursors can be avoided by different kind of JOINS, sub queries etc. So think, analyze and if needed take help of others before writing any cursor in your procedure. In one of the optimization task that I worked on I improved the query performance more than 40% by removing cursor from the query.
11. Never Use SELECT * FROM TABLE:
Many of us have tendency of writing SQL using “SELECT * FROM TABLE” format. Do not do it. Even if you need all the columns to be returned, you specify all the columns by their name in your query. Moreover always ensure you are returning only those columns that you really need for your purpose – nothing more than that. This is actually a matter of habit that you can achieve just by not becoming lazy during writing SQL.
12. Print statement:
Sometimes you write lot of print statements to trace your procedure execution. Then after completing the procedure you do not delete those print statements. You should remember event for printing a single digit your processor needs some time and memory. It could be less then micro second but do not forget summation of microseconds become millisecond and summation of milliseconds become second. Yes I have gained almost 1 second performance gain just by deleting all the print statements in one of my optimization task.
13. Using SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY:
SCOPE_IDENTITY, IDENT_CURRENT, and @@IDENTITY are similar functions in that they return values inserted into IDENTITY columns.
IDENT_CURRENT is not limited by scope and session; it is limited to a specified table. IDENT_CURRENT returns the value generated for a specific table in any session and any scope. For more information, seeIDENT_CURRENT.
SCOPE_IDENTITY and @@IDENTITY will return last identity values generated in any table in the current session. However, SCOPE_IDENTITY returns values inserted only within the current scope; @@IDENTITY is not limited to a specific scope.
For example, you have two tables, T1 and T2, and an INSERT trigger defined on T1. When a row is inserted to T1, the trigger fires and inserts a row in T2. This scenario illustrates two scopes: the insert on T1, and the insert on T2 as a result of the trigger.
Assuming that both T1 and T2 have IDENTITY columns, @@IDENTITY and SCOPE_IDENTITY will return different values at the end of an INSERT statement on T1.
14. Using @@ERROR:
Make sure that the @@ERROR global variable is checked after every statement which causes an update to the database (INSERT, UPDATE, DELETE). Make sure that rollbacks (if appropriate) are performed prior to inserting rows into an exception table
15. Minimize using Not Equal operator:
Minimize the use of not equal operations, <> or !=. SQL Server has to scan a table or index to find all values to see if they are not equal to the value given in the expression. Try rephrasing the expression using ranges: WHERE KeyColumn < 'TestValue' AND KeyColumn > 'TestValue'
16. DONOT start the name of a stored procedure with SP_: This is because all the system related stored procedures follow this convention. Hence a valid procedure today may clash with the naming convention of a system procedure that gets bundled with a Service pack / Security patch tomorrow. Hence do not follow this convention.
17. Using Indexed View:
Sometimes we would require an view to be indexed. This feature is bundled with SQL Server 2000. The result set of the indexed view is persist in the database and indexed for fast access. Because indexed views depend on base tables, you should create indexed views with SCHEMABINDING option to prevent the table or column modification that would invalidate the view. Hence using them can reduce a lot of load on the base tables but increases the maintainability.
18. Readability:
i. Ensure the readability of your SQL.
ii. Capitalize all key word like SELECT, WHERE etc.
iii. Use camel casing in naming the variables.
iv. Breakdown your SQL in multiple lines. Never write too long line that can become tough to trace. A very well indented query could be like the following:
SELECT
c.CONTACT_ID
,u.USER_ID
FROM
Cac_Contact c
INNER JOIN
Cac_User u
ON
c.CONTACT_ID = u.CONTACT_ID
End Words:
In this article I have tried to point out the core best practices that you should follow whenever you write any SQL. I have come to learn all of these throw experience rather than study documents or browsing internet. So, I hope this could be practical guide line for all of us in our development to ensure best performance SQL query. Above all you all should remember to ensure the best performance, testing during development has no alternative. So keep tracing your procedures in different scenarios and with different data load so that it can pass any future situation. Be accustomed of using SQL profiler to analyze your query and always keep an eye on the exaction plan that query analyzer generates. I believe above everything patience is the most important thing to improve your SQL’s performance. So don’t get hurry to meet your deadline, because it can cause expensive optimization work to come in front. Rather you take your time to write the best SQL, discuss with your team mates, managers if needed and ensure that you
are writing the best possible implementation of your query.
Nb: Your important feedbacks and contributions on this article are most welcome. Please write mahmud.dev@gmail.com or talk with me verbally for that.