Internal Structures vs. New C # Technologies

If we have developed our own ORM framework and it has worked great over the years, why should we learn and use new .net technologies such as LINQ or Entity Framework or NHibernate or CSLA.NET for our upcoming software projects?

Note. The new framework needs new efforts for education and training.

Note. This is just an analogy.

+4
source share
14 answers
  • As new developers will know newer frameworks, but not yours
  • This way, you donโ€™t have to waste time maintaining the code that Microsoft will support for you.

BTW, LINQ, as such, is a technology that complements your infrastructure.

+15
source

Because what you now have is proprietary and unknown ... and you want to continue to effectively develop your code if you have new staff.

There is nothing wrong with writing your own ORM, but maybe there are some things in Entity Framework 2 that you did not think about - and there the whole team and the community behind it do everything better until your code just becomes obsolete (I I'm not saying that this, by the way, is just an example).

From a personal point of view, knowing nHibernate is a portable skill. Know CompanyXORM is wrong.

+9
source

In my opinion, you should at least check out these new technologies and compare them with the ones you have developed.
Make a list of pros and minus of new technologies compared to what you have, and decide what is best to use in the following projects.

However, if your system is 16 years old, you really should take care that at this moment it will return you to several situations that you will find in new projects.

+4
source

We have exactly the same situation when I work. We have a regular ORM structure created since .NET 1.1.

We are gradually adopting new technologies. Why?

  • Because the .NET platform now offers out of the box everything that has been created with considerable effort. It would be helpful to throw away a large chunk of legacy code in favor of a few API calls.

  • New rewards, such as LINQ, extension methods, lambdas, etc., significantly increase productivity and help optimize code. There is no reason to ignore them.

  • If you are thinking of other ORMs, let me tell you that a lot of very qualified people worked for them, and they probably did it better than you.

  • If you hire new people, it is easier to make them productive as soon as possible if you are based on a common structure. Otherwise, you will receive a long setback until you recognize your infrastructure.

  • If you do not use the latest bells and whistles, many interesting people will not work for you. Or, if you manage to trick them into singing, you cannot hold them for a long time.

+4
source

One more thing you should consider:
cost and benefits

How much does it cost you:

  • maintain your structure, break down errors, improve performance, etc.
  • develop new features.
  • Train your current staff on home improvement and best practices.
  • Train new developers who have never seen your infrastructure.

Another cost is the technical debt you should have: I suppose you really should have a wonderful one. All of these costs (or a large chunk) can be reduced using the new structure.

The benefits that you can get in your current structure should not keep up with the costs you have with them.

+3
source

There are many advantages to using existing frameworks. - Knowledge. Everyone you invite to work with your card will need to study it. On the other hand, there are many people who know how to work with EF, NHibernate, etc.

  • Knowledge. You will find a lot of information, tips, practical advice, books, videos, etc. About the existing framework. If you want to have these materials for your structure, you have the cost of creating them.

  • Knowledge. Try asking a question about your own structure in StackOverflow. The chances of getting an answer are very subtle.

  • Evolution. NHibernate and EF are constantly evolving. The cost of developing your own frameworks is everything, and you cannot share them with other companies ... unless, of course, you sell licenses for it and compete with EF, NHibernate, etc.

    / li>
  • Bugs. This is due to the previous one. You should correct your own mistakes, not just tell them.

  • Agility

    . This is the largest of them. Is your framework easy to use and as fast as a development that uses linq. It is very difficult to build something that also looked like linq.

  • Integration of languages. Microsoft has the advantage of defining a language, which is why it adapts to the infrastructure. For Linq, C # has evolved dramatically. Without these evolutions, Linq would not even exist.

The only advantage is that you maintain your own structure, that you control it. This is a very false sense of security, because you control the structure, but still do not control what you built it on. There is a false sense of security when staying in a comfort zone.

+2
source

The key here is how much time and effort you put into each year to support this 16-year-old structure. You must evaluate other structures to find out if they meet your specific needs and how much direct or indirect costs will be in the short and long term.

+2
source

Of course, there is some pain in the change, but sometimes instead of introducing or supporting the erroneous implementation of something that exists, it is a longer-term strategy for getting something that focuses on any problem domain.

For a specific data access domain, if you are not using LINQ / ADO.NET Data Services / ORM, you will find good reasons in several areas:

  • RESTful API support for accessing your database, which prevents you from performing many contracts and operations in your services.

  • LINQ queries are very efficient for managing data without rounding.

  • Discard the data access model using a stored procedure.

  • Frames / platforms designed to work with these technologies. For example, LINQ works well with WPF / Silverlight, since you are dealing with many IEnumerable collections of your regular C # Object / Data Transfer Objects.

These are just a few reasons, but there are many more. The community was a big reason that I liked to use projects outside the home - either the Microsoft ecosystem, if you choose the Entity Framework or the very dynamic open source community where projects like NHibernate are located.

Although I feel that many people who work on these projects are smarter than me, at the moment I believe that I am as smart as the problem, which is that they spend a huge amount of time on life within this particular area of โ€‹โ€‹concern, while I have other problems that my clients should focus on me. By letting John Smart or Jane have an Intelligent Focus on ORM, I can spend more time on business-related issues (that โ€œoh, yesโ€ is my job).

+1
source

Just because your new employer will not worry about your knowledge regarding your own internal structure. He will request for LINQ or any widespread industry standard at this point in time.

+1
source

I just come to this, even this is a pretty old question.

Well, if you have a framework that has been working for a long time, and you think that it is really good, you probably do not need to switch to a new technology unless you see that the new technology brings you an advantage and eliminates some pains that you have with your current structure. Frames simply become obsolete over time, so if you donโ€™t make very big efforts to maintain your structure, you will move forward one day.

As a rule of thumb, create a proof of concept with a different structure to compare real behavior.

On the other hand:

I worked for a company where some development groups (supported by the company's global policies) thought their structure was better than publicly available. I have never experienced such frustration with using an API that was incorrect, difficult to use, buggy, and completely undocumented. The result was this question . Yes, and I left this company.

Edit:

I noticed that your structure was 16 years old ?! I hope you made a change - even .NET is not old enough to show you how many things have changed. If you donโ€™t work in a mainframe environment (not because you use .NET), where people live for a long time, you should just move forward every few years.

+1
source

I can come up with a couple of reasons.

  • LINQ will help you in many ways (performing all sorts of tasks) and is not mutually exclusive. linq 2 sql is a different repository.
  • There is probably more knowledge and guidance on these public technologies, and then on your infrastructure.
  • Other technologies can be made to work well with these publicly available technologies, where you must do the work for your infrastructure.
  • If a customer ever needs to switch stores, they will have an easier time (this is more beneficial for the customer than you, but I think it is your duty to think about it).
  • it will be easier to attract new employees who already know these public technologies. Most likely, you will not find someone who knows you. Thus, the increase in time for new people can be much less.

therefore, looking at these arguments, I think you need to include the arround question and say. What does my technology have over these others, is it worth it? maybe you can add to public technology?

0
source

If your internal structure is, as you say, older than 16 years, you must reset it faster than Anne Hathaway dropped her Italian fighter working for Ponzi. It just can't be good, unfortunately.

0
source

In many cases, writing your own implementation of ORM / CodeGen / Workflow / Other allows you to be very sensitive to the needs of your application. You can customize your implementation to fully satisfy all requirements and evolve with changing requirements.

On the other hand, this is even more code for which you are responsible for maintaining, testing and debugging. If there are third-party implementations that also meet your requirements, then it is useful to consider them, since this reduces the load on servicing your team. In addition, it will continue to evolve and improve, as this is the primary responsibility of a third party developer. The product may include new features and approaches that you consider useful or could not come up with, or simply could not justify the time spent on implementation. In addition, the amount of investment that you must make in educating new people is reduced because there are more materials available and the likelihood that they are already familiar with the technology.

But let me emphasize - do what makes sense to you. If your current ORM is working well, there is no need to change. When the time comes to make changes to ORM, then it will be useful to consider whether it is worth switching to something else if it meets your requirements.

0
source

Because other developers will hate using it and resent the fact that they use it.

0
source

All Articles