I am going to start a project of my own, which will be ASP.NET MVC + Fluent NHibernate. I want to use test-first approach as much as I can. So, where exactly do I start from? Database schema? Domain model? Mapping domain model classes to the database?
If you have little experience in writing tests, it's the easiest to start from the domain model (or a higher level just below the UI). When you have driven the design of the domain model with TDD, then you will know that what the database schema needs to be like. It may be good to postpone introducing a database to the system, because dealing with database schema migration will add some overhead to the development. And that will also lead to a better design, because then the domain model will be better decoupled from the database layer.
If you are skilled in writing tests and in TDD, it may be beneficial to start from an end-to-end test (in this case they would be written against the web UI) and produce a thin slice of functionality which touches all architectural parts of the system (as recommended in GOOS). In other words, create a walking skeleton. The benefits from this approach are that (1) you will be able to tackle and solve integration problems right at the start, (2) when the end-to-end tests are used to drive the design, it can help you to avoid implementing superfluous parts, and (3) the difficulties of writing the end-to-end tests pressure you to improve the architecture and add monitoring hooks, which may also be useful in monitoring the system in production. (Focused unit test will still be needed, because they provide design pressure at the class level, plus they run faster and thus provide faster feedback.)
I've written more about this latter approach at Design for Integrability.
Requirements gathering.
Start with a mock/prototype (e.g. Balsamiq Mocks) of the application, then writre the views, mocking controllers as you go along, then write the controller logic, mocking the DAO/Repositorys along the way. By the time you start writing your DAO/Repositories, you'll have a good idea of your your required domain objects. Knock those out and use Fluent Nhibernate to build your database.
At least that's they way I'm trying to do things.
I recommend you S#arp Architecture Project that uses best practices combining:
NHibernate
FluentNhibernate
TDD / DDD with model firts approach with Sqlite database for unit testing
Mocking
Repository pattern
You can also install S#arp arch. template for Visual Studio IDE.
Related
After posting a question earlier, I started to wonder if an Entity Framework model (connecting to multiple databases) could run in a web garden with multiple worker processes? Has anyone attempted this?
Absolutely it can, due to EF's Unit of Work pattern it can work remarkably well in a web garden, it's not the ORM itself though that is a significant factor, it's the style and structure of the business logic that will make the difference.
One might even go so far as to say that EF is better suited for this than some other frameworks, but that is highly subjective, so we wont go there...
Unit of Work patterns work really well for REST style or stateless service implementations, if the state is not persisted between requests or across sessions then it is really easy to scale out the service implementation regardless of the framework that you are using to access the database.
That's not to say that a repository pattern can't be effective across a distributed hosting environment, personally I just find that with EF there is less boilerplate code and less effort to get the job done.
EF had a slow start, but it has matured into a very stable product, EF.Core looks to be heading in the right direction too ;)
I am about to start my first project on an ASP.NET MVC 3 web-site. This site will have data storage and I am wondering what's the best way to deal with the evolutionary design of the database behind the web-site - after the site launches, it will be extended and it will keep on growning thus database refactoring will be an issue. What's the best way to deal with this "problem"? I was thinking of using an ORM like NHibernate or Entity Framework, but neither of them support evolutionary database design.
Any help is appreciated.
Are you looking for migrations support for .NET primarily?
https://stackoverflow.com/questions/313/net-migrations-engine
https://stackoverflow.com/questions/8033/database-migration-library-for-net
.NET migrations: Setup and migrate multiple databases at runtime
I can assure you that developers are doing evolutionary database design with both NHibernate and Entity Framework, so it's entirely possible. Maybe you want a highly tooled, automated process though?
I have spent a lot of time searching for best practices for designing a ASP.NET MVC 3 web site using EF 4.1 or another ORM. I found this tutorial on Implementing the Repository and Unit of Work Patterns in an ASP.NET MVC Application . It was a good tutorial and I learned something. So this got me thinking and wanted to know from the people on stack is this something you would use? if not why and how did you design your web site? I just want to learn the correct way to do things and understand why one way is better then the other.
First to say Entity Framework implements a Repository pattern and a Unit of Work Pattern. Implementing Repository and Unit of Work patterns on top of a modern ORM like Entity framework is an additional layer of abstraction that:
narrows the possibilities of the underlying ORM
does not provide additional value to the underlying ORM
is at best worthless but may be harmful
One purpose of such implementations is to encapsulate the query logic in the Repository and not one query like Single Responsibility Principle (SRP) would suggest, but a couple of queries and thus violating SRP. What you could do is to rely on your ORM and encapsulate extensive query logic in single Query classes.
My suggestion is not to please "best practices" by adding abstraction layers on abstraction layers and so on but to try to solve a problem using some more general design guidelines such as SOLID.
Ayende Rahien reviews the Northwind Starter Kit application in a series of blog posts (here, here, here, here, here, here, here and here) in his blog that deal with so called best practices applied in an application. This is a great read!
I've been seeing a lot of articles and references about how to use this patterns for my first (please keep this in mind) serious project with ASP.NET MVC 3 and EF.
The project is not so big (13 tables) and it's basically a CRUD maintenance: organisations that have some users; users that can belong to a group and can create some work areas and templates... Nothing complicated. The point is that this will be the first of a project series and I'd like to create a base to work with.
My questions are:
Which of the previous patterns is the best? Does it depend of the project size?
My models would be these:
Unit of work
Dependency Injection
Do you think they are good enough and appropriate for my project?
I appreciate all your comments.
Serious application doesn't mean to be complex at first sight.
Over engineering an application upfront can be a real disaster, especially if you don't grasp all the technologies involved.
My advice would be to keep it simple. Create a basic application that fulfill requirements (get the thing done and make your boss happy) and then add new concepts along your learning path.
That doesn't mean I promote bad code, no way! Keep your code clean, well organized, etc. But don't be killed by the fear of doing something wrong.
It's normal for a developer to look back to an application made a few weeks ago and then realize that he did some shitty stuff. That's how we progress!
Last but not least, have FUN!
ASP.NET website provides usefull resources to learn the framework and all related guidances. There are a few application samples created step-by-step.
ASP.NET MVC was built with Dependency Injection in mind.
If you want to give a chance to your code to be loosely coupled and easier to change in the future you have to follow the patterns like Dependency Injection, Repository (for presistance abstraction), and UoW (for transaction abstraction).
So my answer is, you should learn about them in the first place to decide after if you want or no to follow the best practices. Even for simple project it's good to apply these patterns because often it gets bigger and bigger. and it's easy to do it in MVC so why to avoid it ?
There is many resources around to learn about. You can just google it.
I would like to answer this question in more generic way. Creating something which can be used in future is difficult than what it seems. All the pattern above can provide you infrastructure pieces to come up with some base framework.
But I would strongly suggest you to look at S.O.L.I.D principals (DI being part of it) to understand some qualities of good code. These are applicable irrespective of the technology involved.
You cannot predict the future requirement of a product\framework, but following these principle you can be better prepare to handle any future modification to the software
You might want to check out S#arp Lite which has many good examples of how to implement the things you want and can serve as a very good base on which to build something quickly.
None of the mentioned patterns are mutually exclusive. You should use the patterns that make sense based on what you are trying to accomplish, not attempt to shoehorn your application design into someone elses idea of how it should work. Sometimes trying to bend your scenario to fit a particular design pattern / practice is the worst thing you can do.
Want to make sure good unit test coverage / do TDD / ensure loose coupling? Then Dependency injection is your friend, as is the Unit of Work pattern. This is definitely a good idea for creating a maintainable, scalable application, but you can go too far with it for a small-scale application.
Need a centralized caching strategy for your data source? Then use the repository pattern. Or an ORM like NHibernate, which might do it for you.
I am building a second Rails web-app from scratch. I am wonder what would be the best practice in terms of workflow:
start coding basic functionalities, then add GUI design and repeat,
or
create full set of wireframes for basic functionalities, then
design data and models, then code it up, then repeat
It seems to me that laying out wireframes forces me to think harder about how users will use the app, but choosing work-flow kinda depends on framework (support agile development or not).
What is your approach and what're pros and cons?
Thank you.
There's no "best"; it depends on what's actually happening.
You may know some basic functionality before beginning workflow design, but it's unlikely you'll know all of it. Either way, high-level behavioral tests are a good place to start defining functionality at both the UX and lower levels.
I'm not sure what you mean by "support agile development or not", that doesn't have anything to do with the framework. The framework shouldn't have an impact on workflow, either, only on how the workflow is implemented.