As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Any thoughts/comments on a database with over 3,000 stored procedures querying/accessing over 1,400 tables (overly normalized). Really want to use technologies such as Entity Framework, preferrably 4.0, and get the business logic out of those sproc's?
Appreciate any real-life practical experience & feedback if you decide to share. This is a database I inherited and really feel like it's time to ditch the sproc's for a better business layer.
Not really an answer to your question, but you can still use sprocs in Entity Framework: see here, basically sprocs map to method calls on your context object.
My personal experience is actually the opposite to yours though: I've usually tried to stay away from EF because it has this tendency to become so tightly coupled with your application. The nice thing about sprocs is that they allow a degree of de-coupling (e.g. I can update the database without modifying client code). But that's just my personal opinion of course.
This depends on the shop you work at. I've worked at many shops that have conflicting strong opinions about whether or not to capitalize on sprocs, or code in the application layer. The question is: do you have more people that are expert at maintaining plsql/tsql or not?
Personally I used to hate sprocs, and favored orm tools, etc. Now days I prefer to keep the application code clean. This is only after getting really comfortable in the database. Let the database code exist in it's native environment, with all of the tools available to it.
Why use Stored Procedures?
In practice, you'll end up refactoring away from EF in a few years whereas your stored procs could still be sitting there ready to use in the latest and greatest client layer. Client agnostic, encapsulating, etc.
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
When building an MVC application from scratch without a pre-existing database, is using the code-first approach the best way to do it?
While most applications are database-centric, it is perhaps the schema rather than the database itself that governs how the app is built around it. As such, I think a code-first approach isn't too bad. It was late to the party (happened after database-first and model-first), but I think the code-first approach will become the norm soon.
What's your opinion?
First i think that this link can provide you with more information
In my opinion both of the approaches are useful. A developer/company needs to decide what is the best approach for there system, in some situation.
I think one good distinguish is Big and complex against small and simple applications
I think that developers or companies will prefer "DataBase First" approach when they builds complex application. In most cases DBA's will be needed in such project.
In those cases the project will include Store Procedures/ Triggers and maybe also a Data-ware house
In the other hand when you build a small application with one of small group of developers you probably prefer using "Code First" approach
again this is my opinion...
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
What is the most popular design pattern in web app?
I know that in asp.net mvc often used dependency injection and repository, but I want to know which additional patterns can I use in web apps. And it would be best if you give me sample of situation in which I can use patterns, or give code snippet.
Most of the design patterns we've developed as software engineers over the last few decades are still applicable for the situations they were designed for. Depending on your needs you will use most of these in web apps at some point.
http://geekswithblogs.net/subodhnpushpak/archive/2009/09/18/the-23-gang-of-four-design-patterns-.-revisited.aspx
Also below is a link to a site that shows quite a few of these patterns and has explanations / examples. They have their own product, which the site is a shop front for, but the site does have examples and contain code samples so may be worth a visit if you feel like it. most in C#
http://www.dofactory.com/Patterns/Patterns.aspx
Singleton is the most popular pattern. It is also one of best know anti-pattern (patterns that are considered to be harmful).
Every newbie uses it, because it lets you use global state, that looks like object oriented code. It also lets you avoid, that confusing dependency injection thing.
As for the "Gang of Four" book, there has been a movement by some uneducated people to remove the Singleton pattern in latest editions, but the attempts has been successfully thwarted.
Or if you have $28... C# Design Strategies with Jon Skeet
I haven't watched it but I do plan to buy it soon.
edit: IMHO the most popular design pattern in asp.net web development is the Smart UI anti-pattern ;)
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
Just starting a new asp.net mvc solution and one of the requirements is the ability to scale for potentially millions of users at later stage.
I'm planning to use a generic repository that exposes IQuerable and use linq in the service/application level (I know It's not a pure DDD approach but this is not the debate :) ). I'm planning EF as ORM for dataaccess (with a distributed cache as second level cache to acheive the scalability at some extent)
The issue I will be facing is all those linq queries not compatible with any future NoSql linq provider (The Joins are unlikely to be supported in NoSql linq provider).
But I'm willing to take the risk of having to rethink all those linq queries as long as they are all located in one place : the service/application layer.
What would be a better approach? any recommandation ?
A NoSQL database wont solve problems that a RDBMS can't. Only well designed tables can.
I would use a NoSQL solution like RavenDb (since you are in .NET) from the start to decrease the development time and not switch later on.
Use CQRS if you want your application to scale. No need for an external query cache from start. Just do the interfaces so that you can switch to an external cache (or query DB as some call it) later on.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I have a Rails app with 600 models and that will soon grow to 800-1000. I'd like to segment the rails app so that only certain models get loaded and therefore act as a separate app, but all share the same base models. Is there a standard practice for doing this?
EDIT: I am on 2.3.8
EDIT 2:
The problem is that many models are similar, but different just enough that it warrants writing a new class, i.e. the logic required to put it all in one model would be horrendous. Some of the models could be moved out into rake tasks or the lib directory, but only about 30 or so. Some are abstract classes that act as parents of one arm of the model tree. However, most relate to database tables. I am thinking about at deploy time segmenting parts of the app into plugins via Engines so that one app can only handle one set of models (they are independent) but so that I can keep them all together in development and in one git repo for convenience. I"m going to go down this route unless someone else has a better idea, and I'll post back to let you know how it goes.
Dude, thats a pretty insane amount of models... anyways for handling complex logic and easily reuse them across other projects I would recommend to you the engines (from 2.3+ is part of Rails).
With that in place you can split your model in different modules (engines)
http://railscasts.com/episodes/149-rails-engines
Toño
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
I am working as a PhD student developing scientific/engineering simulations and algorithms to be tested in these simulations. These days the first student started to work on my project (for his Bachelor thesis) and I am wondering: how should I organize the project now?
I think I have some good C++ knowledge (although I still want to improve every day) and the code contains some design patterns, lots of templated classes etc. These techniques are new to the student and I wonder if it's a good idea to have him work directly in the trunk of the project.
Do you have any experiences what happens if programming newbies and more experienced programmers are mixed? Does the code get messed up or do the newbies learn more by this? Is it wise to have a branch for the student to test his algorithms and maybe merge them into the trunk later? Should I first give him a book like The Pragmatic Programmer for reading (better suggestions?)?
Constant code reviews are an excellent way of a) improving the quality of committed code and b) helping the newer programmers get up to speed, integrate and rapidly learn.
We use code reviews and it really does help in so many ways.
Edit: Another advantage of code reviews is that it gives people a chance to describe why they did something the way they did - code reviews are a two-way process, and both parties can benefit from them. Remember, jsut because they're new, doesn't mean they don't have something to teach you.
So long as the students understand that code reviews are a well-accepted industry practice with no small amount of research backing it up, that it isn't intended to babysit newcomers, and that even experienced programmers use code reviews, it should work out fine.
If it helps, have them take part code reviews of more experienced programmers.