We are developing LOB apps for many potential customers that are small or mid size, not large.
We will have to install the database for each new customer.
What do you think is the best approach for us, Model first (using edmx and using the wizzard to develop the model and metadata) or Code First.
We like the simplicity of Entity Framework/RIA Services, and we think that the Optimistic Concurrency is enough for our apps, but as the database must be installed from scratch in SQL Server (we won't use other database), we are not sure what approach is best for us.
As long as EF and the choice about edmx/code first I believe it's more a matter of personal preferences. Edmx model seems easier than code first however the designer is still a bit clunky even in VS2012 especially if you have 50+ entities. I've abandoned edmx since EF code first has become usable.
About WCF Ria Services I use it extensively in my LOB applications, even in a large one and most of the time it saves you a lot of glue code comparing to plain WCF. I'm sure you know about the well published features such as
server side filtering, paging and even grouping
Client code generation that ease the sharing of code between sl and the full clr
and many others, but maybe you're more interested in his limitations
you can't query from the client with a nested expression (i.e. Any) though you can always add a parameter to your query and apply the filter server side, but it's not quite the same
you can't directly expose many to many relations with silverlight (have however a look at M2M4RIA)
you must add the foreign key field to your model (to me it seems like DB leaking into the the model)
WCF Ria services do most of his work in the main thread (i.e. loading the DomainContext after a load/submitchanges)
If your application get big and you're thinking to split your domainservices/domaincontext, be aware that you'll encounter serious pain trying to submit the changes of the two domaincontext in an atomic transaction
Proxy generation will happen everytime you build your client and take (I think) longer than it should
Despite that I believe it's a good technologies for RAD and things may eventually turn better: Colin Blair has posted on his blog that him is pushing Microsoft in order to release WCF Ria as opensource, and this can really improve things given that Microsoft has killed Sl/Wcf ria development
Related
I have been investigating NServiceBus. I liked the idea of the pub-sub model, and that the only real coupling of the publisher and subscriber is the semantic of the message. Right now we use SQL replication to sync our data between the databases of different functional areas of our software. I hate this because our private schema is directly coupled to by the subscriber, and it makes it difficult to change on our side. I was thinking it would be great to replace this with NServiceBus publications, but the change seems a little drastic. What about just using something like SSIS? Can I accomplish the same decoupling using SSIS instead of NServiceBus?
SSIS is based on meta-data and therefore will still need to understand the inner schema of all your data sources and sinks. If the underlying meta-data for each source/sink changes your packages will have to change. You also are connecting via MS technologies and are thusly platform coupled. Since you are moving whole sets of data around it sounds like you may not be temporally coupled(system A has to wait for something to respond in system B). It's hard to tell without knowing more about the systems. Lastly SSIS must be aware of the physical locations of all the players in the exchange so you are spatially coupled as well.
In my opinion I don't think you can get to the same place as NSB without developing a lot of the NSB concepts into the packages. This would require using XML messages over the Sql Broker or something to that effect which has already been solved in NSB(see the NSB Contrib project on Github for the Sql Broker transport).
I'm going to start a new project which is going to be small initially but may grow to big over the years. I'm strongly convinced that I'm going to use ASP.NET MVC with jQuery for UI. I want to go for MySQL as database for some reasons but worried on few things.
I'm totally new to Linq but it seems that it is easier to use once you are familiar with it.
First thing is that accessing data should be easy. So I thought I should use MySQL to Linq but somewhere I read that it is not directly supported but MySQL .NET connector adds support for EntityFramework. I don't know what are the pros and cons of it. DbLinq is what I also heard. I would love if I can implement repository pattern as it allows to apply filter in logic layer rather than in data access layer. Will it be possible if I use Entity Framework?
I'm also concerned about the performance. Someone told me that if we use Entity framework it fetches lot of data and then filter it. Is that right?
So questions basically are -
Is MySQL to Linq possible? If yes where can I get more details on it?
Pros and cons of using EntityFramework or DbLinq with MySQL?
Will it be easy to access data using EntityFramework or DbLinq with MySQL?
Will I be able to implement repository pattern which allows applying filter in logic layer rather than data access layer (when I use EntityFramework with MySQL)
Does it fetches hell lot of data from database and then apply filter on it?
If it sounds too many questions from my side in that case, if you can just let me know what you will do (with a considerable reason) in this situation as an experienced person in this area, that should answer my question.
As I am fan of ALT.NET I would recomend you to use NHibernate for your project instead of EntityFramework, you may google for the advantages over it, I am convinced you'll choose it.
Based on the points you've mentioned, then I would seriously consider going with MS SQL instead of MySQL initially and implementing LINQ-to-SQL instead of Entity Framework, and here's why:
The fact that you are anticipating a lot of traffic initially tells me that you need to think about where you plan to end up, rather than where to start. I have considerably more experience with MS SQL than I do with MySQL, but if you're talking about starting with the community version of MySQL and upgrading later, you're going to be incurring a significant expense anyway with the Enterprise version.
I have heard there is a version of LINQ that supports MySQL, but, unless things have changed recently, it is still in beta. I am completing an 18-month web-based project that used ASP.NET MVC 1.0, LINQ-to-SQL, JavaScript, jQuery, AJAX, and MS SQL. I implemented the repository pattern, view models, interfaces, unit tests and integration tests using WatiN. The combination of technologies worked very well for me, and I plan to go with the same combination for a personal project I'm developing.
When you get MS SQL with a hosting plan, you typically have the ability to create multiple databases from that single instance. It looks like they give you more storage because they give you multiple MySQL databases, but that's only because the architecture only supports the creation of one database per instance.
I won't use the Entity Framework for my ASP.NET MVC projects, because I wasn't crazy about ADO.NET in the first place. I don't want to have to open a connection, create a command object, populate a parameter collection, issue the execute method, and then iterate through a one-way reader object to get my data. Once you see how LINQ-to-SQL simplifies the process, you won't want to go back either. In the project I mentioned earlier, I have over 60 tables in the database with about 200 foreign key relationships. Because I used LINQ-to-SQL with the repository pattern in my data layer, I was able to build the application using not a single stored procedure. LINQ-to-SQL automatically protects against SQL injection attacks and support optimistic and pessimistic concurrency checking.
I don't know what your project is, but you don't want to get into a situation where you're going to have trouble scaling the application later. Code for the end result, not for the starting point, and you'll save yourself a lot of headaches later.
I've been evaluating MindScape Lightspeed for the purpose of Model creation. So far I am satisfied. I was further looking for OOTB (actually some professional quality code) providers for MySQL for ASP.Net. I've come across 'dotconnect for MySQL' from Devart. This looks like fitting the bill for the latter requirement. It also has 'Entity Developer' for creating Entity Models (I discovered this a little late). I have however not evaluated this. I surely want to go ahead with dotconnect for the purpose of using various providers but I am not sure how good Entity Developer is in comparison to MindScape Lightspeed. This question stems from the fact that I am a very (ready as very very) small shop and I would like to invest smartly even if it is a matter of $100.
First off, I work for Mindscape - just to get the disclosure of the way :-) I'm not a devart customer and perhaps somebody could add additional information if they've used their tools. To state what the products are you're looking at:
Entity Developer - a designer tool for creating a model. It allows you to generate a model for LINQ to SQL or LINQ to Entities. There are already designers provided to do this by Microsoft however the tools provided by devart appear to be superior and may be worth the price if you have issues with the default tools.
dotconnect for MySQL appears to be a provider that lets the Entity Framework talk to MySQL. By default the Entity framework provides no capability for this but does provide a plugin framework so that developers can build providers (in this case, MySQL). I could be wrong here but that's how it looks. This means the ORM factor is controlled by Microsoft and you would have the capabilities and release cycle dictated by Microsoft (this can be a good or bad thing depending on your requirements :-)
LightSpeed on the other hand is a ground up ORM that Mindscape have developed. It does no re-use Microsoft technologies other than integrating our designer into Visual Studio. This means our ability to respond to requests is superior to that of Microsoft. We have baked in support for MySQL as well as many databases meaning if you purchase LightSpeed and later do another project using a different database engine you won't need to purchase another product. We have published a rough guide to the underlying differences between LightSpeed and the Entity Framework in our orm comparison document (note: it's based on comparing to the Entity Framework delivered with .NET 3.5, not the one coming out next year).
In terms of the designer, I'm not sure how they compare in detail. The LightSpeed designer has supported schema round tripping for a long time (meaning if you change the model in the designer you can push changes to the database OR if you change the database you can right click and update the model based on the database changes - whatever works for you). With LightSpeed 3.0 which we released today, we also auto track migrations so that you do not need to manually create SQL files to migrate your database schema as you evolve your solution. If you wish to alter the templates for the generated code you are welcome to do so - which seems similar to what the devart designer allows.
Having said all this - if you're looking for Visual Studio support for the basic ASP.NET controls (like table adapters) then you would likely find a better bet with the devart product because it surfaces that sort of thing better. You can technically use LightSpeed with these by wrapping LightSpeed entities with an ObjectDataSource in most cases but it's an additional step.
On the whole, I can appreciate that the products appear similar-ish but are actually quite different at the same time. I haven't listed out pro's and con's because it absolutely depends on what you're looking for and the type of project you're building. I appreciate your feedback as you find out more - let me know what you discover :-)
Also - if you have any further questions or if you'd just like to have a chat about your requirements in more detail please use the contact form on our website - I'm happy to help!
I am part of a team developing a windows application. We have decided to use LINQ-to-SQL. We are using the designer to generate the classes.
There are few things I would like to know
Do you load some data (master), and keep it in memory?
Are you using DDD principles?
I would like to know how you have handled various scenarios in a windows application.
If you have a Windows application (rich client), then yes, certain bits and pieces might make sense to be loaded at startup (or when they're being used first), and then retained in memory. Things that you need frequently, and that don't change too much - things like information on your current user, or other things like that.
Linq-to-SQL is based on an existing database - it basically scan the database and creates classes from that. It doesn't really have a "model-first" domain-driven design approach. If you're more into creating your domain model first and deriving your database from that, I would recommend checking out the Entity Framework v4 that will ship with .NET 4.0 in March 2010 - that's quite specifically designed to do "model-first" / DDD scenarios.
First a bit about the environment:
We use a program called Clearview to manage service relationships with our customers, including call center and field service work. In order to better support clients and our field technicians we also developed a web site to provide access to the service records in Clearview and reporting. Over time our need to customize the behavior and add new features led to more and more things being tied to this website and it's database.
At this point we're dealing with things like a Company being defined partly in the Clearview database and partly in the website database. For good measure we're also starting to tie the scripting for our phone system into the same website, which will require talking to the phone system's own database as well.
All of this is set up and working... BUT we don't have a good data layer to work with it all. We moved to Linq to SQL and now have two DBMLs that we can use, along with some custom classes I wrote before I'd ever heard of Linq, along with some of the old style ADO datasets. So yeah, basically things are a mess.
What I want is a data layer that provides a single front end for our applications, and on the back end manages everything into the correct database.
I had heard something about Entity Framework allowing classes to be built from multiple sources, but it turns out there can only be one database. So the question is, how could I proceed with this?
I'm currently thinking of getting the Linq To SQL classes all set for each database, then manually writing Linq compatible front ends that tie those together. Seems like a lot of work, and given Linq's limitations (such as not being able to refresh) I'm not sure it's a good idea.
Could I do something with Entity Framework that would turn out better? Should I look into another tool? Am I crazy?
The Entity Framework does give a certain measure of database independence, insofar as you can build an entity model from one database, and then connect it to a different database by using a different entity connect string. However, as you say, it's still just one database, and, moreover, it's limited to databases which support the Entity Framework. Many do, but not all of them. You could use multiple entity models within a single application in order to combine multiple databases using the Entity Framework. There is some information on this on the ADO.NET team blog. However, the Entity Framework support for doing this is, at best, in an early stage.
My approach to this problem is to abstract my use of the Entity Framework behind the Repository pattern. The most immediate benefit of this, for me, is to make unit testing very simple; instead of trying to mock my Entity model, I simply substitute a mock repository which returns IQueryables. But the same pattern is also really good for combining multiple data sources, or data sources for which there is no Entity Framework provider, such as a non-data-services-aware Web service.
So I'm not going to say, "Don't use the Entity Framework." I like it, and use it, myself. In view of recent news from Microsoft, I believe it is a better choice than LINQ to SQL. But it will not, by itself, solve the problem you describe. Use the Repository pattern.
if you want to use tools like Linq2SQl or EF and don't want to have to manage multiple DBMLS (or whaetever its called in EF or other tools), you could create views in your website database, that reference back to the ClearView or Phone system's DB.
This allows you to decouple your web site from their database structure. I believe Linq2Sql and EF can use a view as the source for an Entity. If they can't look at nHibernate.
This will also let you have composite entities that are pulled from the various data sources. There are some limitations updating views in SQL Server; however, you can define your own Instead of trigger(s) on the view which can then do the actual insert update delete statements.
L2S works with views, perfectly, in my project. You only need to make a small trick:
1. Add a secondary DB table to the current DB as a view.
2. In Designer, add a primary key attribute to a id field on the view.
3. Only now, add an association to whatever other table you want in the original DB.
Now, you might see the view available for the navigation.