From the free and proven IoC containers/frameworks, please let me know which ones you prefer to use and what makes you choose that one instead of the others?
Thanks in advance for your inputs.
.net, Architecture, best practices, C#, Code Improvement, Dependency Injection, Development, free tool, IoC, quality
Don’t you ever wonder to print out that whiteboard or have it emailed to you?
We often take photos of the drawing and it makes sense only if the drawing is not too larges.
Not to mention that those pens smell bad often times and they go low in ink etc when you need it most.
Here is a solution (expensive solution though $1000.00+)


Wanna buy? Try this: http://www.fatcatalog.com/pd/34630/electromagnetic-interactive-dual-pen-whiteboard-with-hot-keys-88-diagonal
Architecture, Design, Development, Every dev teams dream, quality, Simplicity
It is actually not difficult to move your asp.net application to Azure even if you are using Sessions.
This is just because of the services offered by Azure Cache. In the end, you only need to make few changes your web.config and you will be running your session through distributed cache which is provided by Azure Cache.
In simple terms, the following is the only thing you need to do:
<sessionState mode=”Custom” customProvider=”DistributedSessionProvider”>
<providers>
<add name=”DistributedSessionProvider”
type=”Microsoft.Web.DistributedCache.DistributedCacheSessionStateStoreProvider, Microsoft.Web.DistributedCache”
cacheName=”default” applicationName=”Contoso”
useBlobMode=”true” />
</providers>
</sessionState>
Please read more @ http://msdn.microsoft.com/en-us/library/windowsazure/gg185682
.net, Architecture, asp.net, Azure, Caching, Cloud, Development, Session
Finally SevDer ORM+ had a long way so far and almost ready.
I would like to share the first preliminary screens.
Tool will be completed by tonight/tomorrow I hope.

Here you just need to select the profile or just start building one.

Very simple profile setup..

Code Generation based on selected Profile (ORM)
Here you go with code generation, ORM kicks the way you need!
As you see even it generates ASCX files (I will in the future add ASPX option and MVC/RAZOR too, but not yet)
.net, Architecture, best practices, C#, Code Improvement, Development, SevDer ORM Plus, SevDer ORM+, Simplicity
After getting frustrated with the fact that Entity Framework and NHibernate does not resolve my needs, I am writing my own ORM tool to finalize one very important part of enterprise architecture.
Here are the features that are included (hope to finish by tomorrow)
- Mutliple entity classes (one per each)
- Single Data Provider Class
- One Interface IDataProvider
- One Class which inherits I[Model]DataProvider (SQL[Model]DataProvider)
- [Model] to be renamed by the model name provided
- One mocked class using moq framework (http://code.google.com/p/moq/)
- SQL[Model]DataProvider will also implement retry logic in case of certain cases such as
- Deadlock
- Connection Timeout etc.
- In a nutshell the following error codes : -1,-2,2,53,1222,1205
- Will obviously generate related stored procedures and utilize them
- Entities will be able to track simultaneous changes and will be able to throw exception if data changed before update!
- Entities will implement [DataContract] & [DataMember] so that usage in WCF will be a lot easy
- As you may see from here generated codes will implement Abstract Factory (Provider) design pattern and possibility of Singleton is also there.
I think all of those will give me the best ORM that I would need.
I’ve named it as SevDer ORM+ and first version will be completed by tomorrow
.net, Architecture, best practices, C#, Design, design pattern, Development, Entity Framework, free tool, quality, Simplicity, unit testing, WCF
After doing enough research on both, what we’ve end up doing is; not using any ORM tool.
ORMs are designed to do rapid development for RIA (Rich Internet Applications) where performance is not a big concern.
Yes, ORM can speed up your development such as EF 4.0 or NH but they all lack one very important thing which is support for Stored Procedures for general select which shall be by default. All ORMs are focused on eliminating that and trying to optimize queries without SP.
If you ask me, SP are most useful when you use for select in general because you can really optimize the execution plan and it will be cached on SQL server. So in all subsequent calls to the database with same routine, SQL server will always know the execution plan and it will save time. [SP's execution plans are cached on SQL server.]
Therefore not using ORM is my choice.
Here are what I lose by not using ORM
- oData
- Extra quick development
- Default behavior of throwing exception on an update where data was already changed before the update (concurrency handling)
What I gain by not using ORM
- Will get the best performance
- My code will not have unnecessary extra code which I may not even use
- Will use SP’s the way they are supposed to be used
- Will abstract data layer in the most perfect manner
- Improve existing code generator to do my own ORM (no oData)
- All entities will be generated with DataContracts, DataMembers (necessary in WCF)
- Proper implementation of RETRY logic in SQL Exceptions (if you ever want to move into SQL Azure, you need to do this also)
- Will implement concurrency handling
As a result, I have tons of gains by not using .
Most important is achieving best performance and SP usage on selects.
I hope I’ve helped.
Please let me know if any more digging in this is required.
.net, Architecture, Azure, best practices, C#, Cloud, Development, EDM, Entity Framework, ORM, Simplicity, WCF, WCF Data Service
We are comparing to select the next robust data layer and almost in the end
Here are the requirements
- Needs to be available as a service
- Very important to segment out security to limited resources [PCI]
- Very helpful when testing [helps in mocking also]
- Needs to be easy to adopt
- If possible build in minutes
- Needs to be flexible in migrations/versions
- Needs to work with existing stored procedures
- Shall force developers write better code
Given those here are the comparisons and the choice
NHibernate the good
- Most mature and longest in market
- Easy caching
- Versions are not big issue, backwards compatible
- Lazy loader per entity
NHibernate the not good
- You need to still write a lot of code
- No designer/GUI
- Service is not provided out of the box
- Longer learning curve
Entity Framework the good
- Easy to build with GUI support [in minutes]
- Easy to convert to service in minutes also
- Easy Lazy loader for the whole model
- Migrations/versions are manageable and will support earlier version clients with few tricks
- Works with existing procedures
- Links entities without any effort
- Code First, Model First, Database First Support
- Data Changed notification [Don't know if NHibernate has this]
Entity Framework the not good
- Not yet mature enough
- Caching is not provided out of the box
- Select procedures are not that easy like Delete, Update & Insert
- Default behavior may make developers yield to, not to use stored procs hence poorer performance may occur & worst of all deadlocks can occur [not so different in NHibernate also]
So at this moment EF 4.0 + WCF DataServices is my choice to move forward, starting tomorrow.
Ohh friends, please correct me in the areas where I am not correct.
.net, Architecture, best practices, Development, EDM, Entity Framework, NHibernate, WCF Data Service