I'm a new comer to the Scaffold world to build repositories creating the CRUD operations.
There are a lot of scaffolding templates ,I'm so confused which one will suit my requirement .
I use asp.net web forms (not asp.net MVC)
I use Entity Framework 6 as ORM .
I want some help to clarify the main pillars we select one scaffolding template over one and what's the proper one for my case ?
NOTE : Right now i use T4Scaffolding .
I think you can use T4Scaffolding, as you already do. But why are you using a "scaffold"? I created my crud app with entity framework without scaffolding anything.
Anyway, the scaffolding tools are all very similar, so T4Scaffolding is perfect, IMHO.
I think you can find interesting this and this.
Let me know if you have other questions.
It looks like you are trying to generate repositories for each model class. If that's the case, my advice will be don't. Moreover, don't be tempted by Generic Repositories (anti-pattern) as well.
For Scaffolding
If you must use scaffolding for generating repositories around your model classes, you may refer to this link for scaffolding repositories using T4Scaffolding.
Note:
If you're using Visual Studio 2013/2015, you would have to use the T4Scaffolding.VS2015 nuget package instead of the older T4Scaffolding package (for older versions of VS).
Aggregate Roots
Firstly, repositories are created on aggregate roots and not per class.
Secondly, although debatable, but EF already implements these patterns.
You many want to read more on repositories; refer t the Matrin Fowler's excellent post.
Why Use Repositories anyway?
Also, there are a bunch of people against it as well importantly for good reasons.
See Rob Conery's post on it. Although, I would prefer using the below solution instead of the one recommended in the post.
The alternate?
BTW, you should consider using commands or tasks instead of respositories. Something like Ayende's post. Of course, you should evaluate your case and come up with your reasons to adopt it. It's just a suggestion, probably a good one ;)
Related
I'm starting out with Xamarin and sqlite, specifically this package:
https://github.com/oysteinkrog/SQLite.Net-PCL
There is no fluent api (IE like in Entity Framework), which is OK, but instead, does anyone have a pattern to keep the attributes, such as [PrimaryKey] out of the domain model so that my domain library doesn't need a reference to the sqlite libraries? The only way I can see is to create separate classes in my sqlite repo library for each of my domain classes, and employ some kind of mapping scheme. But that seems a lot of work just to avoid an attribute. In fact, in this case it's probably easier just to bang out the sql and do it that way instead of using SQLite.Net-PCL's built-in ORM.
It's probably worth it in my case to just litter my domain with the attributes and create a dependency on the SQLite.Net-PCL library.
Are there any other libraries that i can use with xamarin/PCL that might help? Or is there a better technique?
If there really is no configuration-based approach like the fluent API you mention (I don't know of one), you have two options:
Use a separate persistence model
This is usually not as much effort as it initially appears, and it provides real separation of concerns. By going down this path, you also have a natural location for schema migration logic and custom data mappings.
The ugly part of this is the mapping between the persistence and the domain model, which can typically be solved elegantly by using an object to object mapper. For C#, a very good solution is AutoMapper.
Re-evaluate your decision to go with DDD
This is a rather drastic change, but given the fact that you're going to build a mobile app, there is a chance that DDD is a bit heavy anyway. If that's the case*, the door is open to just make the trade-off and have a unified persistence and "domain" model.
*: Take this decision seriously and consider all requirements. Don't base your decision solely on the "implementation detail" problem that you're having right now.
In my project, I trying to implement repository pattern and unit of work.
I found some web site to describe how to implement it such as:
http://www.codeproject.com/Articles/688929/Repository-Pattern-and-Unit-of
http://www.codeproject.com/Articles/561584/Repository-Pattern-with-Entity-Framework-using
I was wondering, why is not generic Unit of Work and Repositories Framework? then try several search on internet and I found it,
http://genericunitofworkandrepositories.codeplex.com/
This framework is first code but my project is model first therefore is not work correctly?
Could you please suggest me model first framework like this?
My project is a internet web site with one database, If there is plausible reason I can change model first approach to code first approach.
Thanks for you time.
We've abstracted all the interfaces in our latest release into Repository.Pattern project https://genericunitofworkandrepositories.codeplex.com/SourceControl/latest#main/Source/Repository.Pattern, in plans to implement nHibernate provider. You are more than welcome to start implementing these interfaces, based on bandwidth at the moment, I cannot commit to any dates as of yet.
this post is meant to have a list of suggestions on MVVM approach... What tools do you use, what do you do to speed up development, how do you maintain your application, any special ways of finding defects in this design pattern......
here is what I do:
So first i create my model/db with EF.
Then I create Views (either user controls or windows) with their respective viewmodel. I usually place the viewmodel in the same location as my view. But while starting the name of my view with "UC-name", I call my viewmodel just "name-model".
In my viewmodel I implement InotifyPropertyChanged
in my xaml view I have a resource of my viewmodel, and bind my grids/controls via the itemsource to the staticresource.
I try to do a lot of front end logic with triggers and styles and also place some code in the xaml.cs file if it regards logic for behaviour of my controls.
I can reach my viewmodel from my view (xaml + xaml.cs).
for communiation between viewmodels I use MVVM lights.
that's pretty much it.
Things I'm thinking about
I'm thinking of using T4 templates for generating viewmodel/view. What do you guys think of this. is this worth it?
when using MVVM light Messenger, we get a subscription based communication, and sometimes I find it hard to track what has changed in my DataContext. Any suggestions on this?
any other improvements or suggestions are more than welcome !
Answering first question regarding View/ViewModel generation I think for CRUD cases it makes sense to use some tools, otherwise it won't be that beneficial.
Pretty nice basic scaffolding implementation example you can find here: WPF CRUD Generator. Also WPF solution by DevExpress looks really promising.
There are at least couple Codeplex projects addressing View/ViewModel generation:
WPF Scaffolder
ViewModel Tool by Clarius
But I am quite pessimistic about T4 for such scenarios. I think writing and polishing own T4's will take you much more time than adoption of existing tools.
Regarding MVVMLight messenger I can say that it will take you some time to get used to it. And as soon as you will understand difference between "regular" and message driven MVVM you'll be able to use it in most efficient way. Very nice article about messenger is Messenger and View Services in MVVM. And want to add a really important quote from there:
A Word of Caution About Messenger
Messenger is a powerful component that can greatly facilitate the task
of communication, but it also makes the code more difficult to debug
because it is not always clear at first sight which objects are
receiving a message. Use with care!
I'm very much a proponent of Domain-Driven Development (DDD). First I have the designer write specifications, roughly adhering to the methodologies in Behavior-Driven Development (BDD). This then forms the basis of unit tests for Test-Driven Development (TDD), for which I use NUnit. For the domain layer itself I start with an Anemic Domain Model i.e. entity classes containing mostly properties and virtually no methods; there are plenty of arguments both for and against this but personally I find it works well. Coupled with this is the Business Logic Layer (BLL) which knows only about the domain entities.
For the Data Access Layer (DAL) I prefer NHibernate, it supports all the usual things you would expect like lazy loading and repository management etc but particularly important is the Object Relational Mapping (ORM) i.e. the bit that translates between your domain entities and the underlying database representation.
One of the problems with NHibernate, in my opinion, is that it uses XML files to do the mapping for the ORM. This means two things: first is that any errors you introduce won't get picked up until run-time. Secondly it's not really a proper "solution" to ORM at all, instead of writing mapping classes you just wind up writing XML files. Both of these problems can be solved by using Fluent. Fluent solves the first problem by replacing XML files with C# files, so your mapping declarations are now done in code which will usually pick up errors at compile-time. It solves the second problem by providing an auto-mapper, which looks at your entities and generates the necessary mapping files automatically. This can be manually overridden if and where needed, although in practice I find I seldom need to. Since the auto-mapper uses reflection is does tend to be a bit slow but it can be run in an offline utility and then saved to a configuration file that is loaded at run-time for near-instant start-up; the same utility can also be used to create your database automatically. I've used this tech with MySql, MS Server and MS Server CE...they've all worked fine.
On the other side of the tier is your view model. I've seen a lot of projects create an almost 1:1 mapping of domain entities to view model classes, I may infuriate MVVM purists by saying this but I really don't see the point in doing all that extra work for something that isn't really needed. NHibernate allows you to provide proxies for the classes it creates, using Castle Dynamic Proxy you can set an intercepter to your NHibernate session factory that automatically injects INotifyPropertyChanged notification to all of your entity properties so that they work with the WPF binding mechanism. Another product, uNhAddIns, allows you to replace any lists with an ObservableCollection in order to get INotifyCollectionChanged support (for reasons I won't go into you can't just put an ObservableCollection into your entities without it seriously affecting performance).
If you're designing and building your application properly using technologies like these and fully unit-testing along the way then you're going to need some way of handling Inversion of Control (IoC) so that you aren't passing object references around all over the place, and for that you'll need a dependency injection framework. My personal preference is Ninject but Unity is pretty good too. Dependency injection is particularly important for good database session management (so that all relevant objects reference the same session), a good rule is one session per WPF form or one per web request.
There are lots of other little things I use to make life easier (MVVM Lite, log4net, Moq for mocking objects for unit testing etc) but this is my core architecture. It takes a while to set up but once you've got it all going you can build fully functional database applications in literally minutes without any of the headaches traditionally associated with layer management in tiered enterprise applications...you just create your domain entities and then start coding for them. Your schema is created automatically, your database is created automatically, you can use your entity classes to fill your database for immediate stress testing and you have full WPF support without having to pollute your entity classes with code or attributes not actually related to the domain. And since all development is driven by anemic domain entities your data is already in the perfect format for serialization into html/ajax/soap etc when you want to give your app web capablities.
You'll notice that I haven't discussed the presentation/XAML layer, mainly because that part is now straightforward. Using a decent architecture you can actually create a fully working and tested application that then only needs pure XAML added to turn it into a releasable product.
I've been working quite som time now to learn how to implement DDD, IoC and ensure there is a separation of concerns in my application. I'm also trying to get in to the way of Test First Development.
Somehow Entity Framework gives med some trouble. I have a domain project that keeps my domain objects (many of them POCO classes now, but with some behavior). It's legacy code, and I try to refactor it, but MVC realies heavily on Dataannotations for validation.
The datavalidation-attributes is set on the domain objects, which ties them to the entity framework. Most instructional videos and documentation on EF also uses a lot of attributes on the domain objects.
So I wonder if this is really a good thing?
I like the idea of many of the attributes, but the consequence of putting them on the domian objects makes me feel that entity framework is the core of the application and not the domain objects.
Do you have any tips on solving this, or is this how it should be?
UPDATE:
The suggested answers below led me to this post answered by Ladislav Mrnka
To me that probably sounds like the best way to go if it solves my problem. He also points out the same problem I have with the attributes in the domain layer.
Do you feel better with Code First Fluent API Validations ?
Some attributes are relevant to EF and MVC - attributes that describe your class. A required field, minimum and maximum lengths, etc... If you really want to separate everything, I'd keep these attributes on your domain objects, put database stuff (foreign keys, etc...) in FluentAPI and MVC stuff (display names, etc...) on the view model.
If MVC 4 happens to support FluentAPI (I'm using MVC 3, which doesn't, don't know about 4), you should definitely use it.
I'm new to the MVC framework and have just run through the NerdDinner sample project. I'm loving this approach over form-based asp.net.
I'd like to spin of a more sizable side project using this same approach. Do you see anything in that project that would prevent me from enlarging the basic structure to a more complex website?
Examples of things that make me wary:
1) The NerdDinner sample accesses a db of only two tables, my db has around 30.
2) The NerdDinner project uses the LinqToSQL classes directly... all the way from the model, through the controller, to the view... is that kosher for a larger project?
Do you see any other parts of the NerdDinner framework that might cause me future grief?
I agree with others that the model should be the only place you use linq2sql and my little addendum to that is only use linq2sql in models in small projects. For larger sites it might be worth the overhead to create a separate Web Service project that does all the talking to the database and utilize the web service in your Model.
I never fully checked out the Nerd Diner example but other best practices include Typed Views and using a datamodeler that allows for easy validation (see xval or the DataAnnotations model binder). To me these are 2 of the most important best practices/
Stephen Walter has alot of excellent tips on his website that are worth checking out and taking into account when setting up a new MVC project.
I would add a service layer between the repositories and controllers. The service layer will contain all of your business logic leaving your controllers to deal mainly with processing form inputs and page flow.
Within the repositories I map LinqToSql classes and fields to domain models and then use the domain models within the service layer, controllers and views. For a larger system the extra layers will prove their worth in the long run.
There's alot of debate around the internet when it comes to the Linq to Sql classes. Some feel that it's not enough abstraction when you use the classes directly, and some feel that that's what they're there for. At work we starting revamping our site, and we're using MVC. The way we decided to go was basically each one of the LINQ to SQL classes implements an interface. IE:
public partial class LinqToSqlClass //generated class
{
public int Id{get;set;}
}
interface ILinqToSqlClass
{
int Id{get;set;}
}
public partial class LinqToSqlClass : ILinqToSqlClass
{
}
This is just a very small part of it. We then have a repository that gets you any of these generated class, but only as that of their interface type. This way, we're never actually working directly with the Linq to Sql classes. There are many many different ways to do this, but generally I would say yes, if you're dealing with a large database (especially if the schema may change) or if you're dealing with data that may come from more than one source, definitely don't use the classes directly.
Bottom line is, there's alot of good info in that Nerd Dinner chapter, but when creating your own project, you'll obviously run into issues of your own so take it as you go.
The Nerd Dinner text makes the claim that the MVC framework can equally well accommodate other common data abstractions. (It's true.) It sounds like your organization already has one it likes. A good learning strategy would probably be to adapt one to the other.