I had a server crash and no access to the server room. But everything should be up and running again.
The repository pattern has been discussed a lot lately. Especially about it’s usefulness since the introduction of OR/M libraries. This post (which is the third in a series about the data layer) aims to explain why it’s still a great choice.
I currently have a number of libraries which I develop (at github). Most of them are small (less than 50kb) and I’m thinking about merging them into one library instead.
What I mean is that I will add them into a single github project.
To me, choice is important. You can always choose to use your own favorite container instead of mine for any of the libraries. However, I also do like to make things easy. For instance, if I want to create a dead easy setup for Griffin.Decoupled I have to create several small nuget packages and make sure that different versions of all libraries work together.
I’m developing more and more features which are cross cutting between libraries, and it is increasingly difficult to manage the differences.
I would join all projects which has no other dependencies than .NET into a single assembly (and therefore only namespaced project). The assembly would probably be about 200kb. All projects that got external dependencies would be named after their dependency. For instance “Griffin.Framework.RavenDb”
You will still of course be able to combine different libraries with other external libraries (as all interfaces will still be there).
Request for comments
What do you think? Do you mind to get a 200kb assembly instead of a 44kb assembly if you for instance only want to use Griffin.Networking or Griffin.Container?
There is a site named plaintextoffenders.com which lists sites which they claim store plain text passwords, i.e. not hashed or encrypted. As proof they let users email screenshots to them.
Many of the screenshots looks like this:
or changed the password
You have successfully changed your password to: XXXX
There is nothing that says that those passwords is stored in plain text in the database. When you register your account or change the password you do type it in the HTML form. Hence it’s sent as plain text to the web server, which then can be used to generate the welcome email.
The only time you *might* have proof of someone storing your password as plain text is if you can request it (like a “forgot password” form). The password might not have been hashed, but it can still have been encrypted. It’s not as secure as hashing (if a potential hacker gets access to the encryption key), but more secure than storing plain text.
I’ve misinterpreted what their goal was. This page explains it.
Email using port 25 is not secure. But most email providers today uses SSL when sending and retrieving emails, which means that man in the middle attacks are not possible. You are only vulnerable for the “email attacks” if the attacker has done the following:
1. Gain access to the router that you or the web site is on (or hacked your computer)
2. Your email provider do not use secure transfers of emails (as most do today).
The chance is imho quite slim which makes this security issue trivial compared to others.
What I’m saying that it’s always important to shed a light on security problems, but don’t scare the users by making them sound bigger than they are.
ADO.NET is actually quite powerful if you use it correctly. This post will teach you everything from making your ADO.NET code driver independent to how to implement the repository pattern and unit of work. This is the follow up post of my “Datalayer, the right way” post. The purpose is to demonstrate that ADO.NET can be used as an alternative to OR/Ms.
The goal with this post is to give you a better understand about how you can design your data layer and why it’s important to create a complete abstraction layer.
If you’ve tried the built in localization features in ASP.NET you’ll probably written cluttered view models like: