We are living in a time where businesses and the people running them often change their mind. I won’t be gong into details of why is that so, let’s just say it is a given, and let’s say they are right. It gives them the competitive edge when they are flexible. It is on us to provide that. We are witnessing a high demand for a maintainable software, software that can change easily over time, and where the most of the effort measured in time and people’s work on projects happens after the initial release…long after the initial release if you’re happy. Needless to say, if we want to software to succeed in the long run, we must set our own mindset towards a way, that will provide the businesses their much needed value in that long run.
I know the following is a bold statement, but, you cannot say this enough so that it doesn’t become true.
There is no silver bullet in software development.
The only thing that separates the good software from the bad one is the value of the software for the business at that particular point in time. In order to prolong the value of the software for a long period of time you have to make it respond easier to change.
How you achieve that is a completely different matter. It borderlines with art and being able to predict the future. But, the good thing is that there are a few guidelines that you can follow that can help you out.
Here, I try to put some light on two of those: cohesion and coupling….Read on…
Continue reading “High Cohesion, Loose Coupling”
Whatever you do in the .NET framework deals either with value or reference types, yet, there seems to be a great deal of confusion in many discussions with fellow developers and on online forums and QA sites about where the actual variables reside. It is so basic yet a cause of so many misconceptions. For example one of them is that value types reside on the stack and that the reference objects reside on the heap. We will try to break up some of those misunderstandings by carefully examining and explaining what really happens(with the current implementation of the .NET runtime, which at the time of writing is .NET 4.5.1)
Before we dig deeper into this issue I just want to say that this is by no means a comprehensive guide to how types are handled in the .NET framework. It would take a whole book on that. I’m simply trying to create a nice picture and get a few things clear as a general concept by working the foundations and trying to create a picture of what is one possibility of what happens behind the scenes down at the deepest level.
Continue reading “Value and Reference”
Problem: Filtering out(removing duplicates) from an IEnumerable
One possible solution with using linq would be to group by key and take the first element of each group. Here’s an example:
enumerable.GroupBy(x => x.key).Select(g => g.First())
In the first part of these mini series we discussed how you can create a custom membership provider and a custom role provider.
Many times you will find yourself in a situation where you need to store and retrieve more data for a specific user than it is available in the MembershipUser class, which is the default for a MembershipProvider.
While there is a way to acomplish this by using profiles and the ProfileProvider class here I will show you how to accomplish this by creating a custom membership user.
Continue reading “Custom Membership User”
In the first part of these series we discussed and provided an example of how to create a custom membership provider. We will continue these mini series with a discussion and an example of how to create a custom role provider. We said in the first part that the reason of why you would like to create a custom membership provider would be if you want to use a data source different than the one supported or if you need to manage role information using a database schema that is different from the database schema used by the providers that ship with the .NET Framework. The reasons of why you would want to create a ciustom role provider are the same.
Custom Membership, Role Providers, Membership User Series.
Since these articles and the examples in them are pretty long, it could get pretty cumbersome to have all of them in one go so I split them up in several articles.
Here goes the first one.
The Custom Membership Provider Implementation
There are many times when the MembershipProvider and its underlying database construction aren’t sufficient enough for our needs. As MSDN states there are two reasons why one would want a custom MembersipProvider:
- You need to store membership information in a data source that is not
supported by the membership providers included with the .NET Framework,
such as a FoxPro database, an Oracle database, or other data sources.
- You need to manage membership information using a database schema that is
different from the database schema used by the providers that ship with
the .NET Framework. A common example of this would be membership data that
already exists in a SQL Server database for a company or Web site.
Continue reading “Custom Membership Provider”