I recently started transforming all tables from our Oracle production into models so I can start using an ORM. I chose Castle Active Record and can really start to see its potential in making my life easier. Since many of the applications I work with utilize the same tables. I figure it would be nice to create a separate library.
My thinking is that if I can successfully separate the database work, table relationships and querying then I can reuse them to my hearts content from project to project. I know for the most part how to create new entities, link them and query what I need based on what is mapped. As of now I have a very simple class library. I could then include generic functions that could be used to query a lookup table and return an id-value pair to populate a dropdown, for example.
Could you please give me some tips and/or personal experiences to achieve this? This will be my first time attempting to create a reusable library of any sort.
Thank you.
I would:
Keep it simple.
Document its public interfaces/methods heavily, especially since you'll use it in multiple projects.
Keep it in source control, which you should be doing anyways, so all projects can easily get updates.
WCF is a popular way to achieve this. Basically you make a bunch of WCF web services that provide access to the data access functions.
This is an ideal place to use interfaces. Store all of your interfaces in a very small, isolated .dll - and you can distribute that. Your consumers can then deal with their own implementations (if I'm understanding you correctly). You could also deploy a standalone component that just has your data structures too.
Related
I am trying to make an application that will load sports data (teams, players, games, etc...) from API and save into the database (with an update once a day) for subsequent analysis (in C#, but I think the language is not that important). The application composes from two parts, one for GUI and second for working with database and API.
My question is: Is it a good idea to use the same classes eg. for teams or players in model for both API and database? I know that one class should have one responsibility, but separate classes seam to me like a little overhead and even bring complications. But maybe I am wrong because I donť have enough experience with architecture design.
Thanks for answers.
If the two classes are the same class that should serve both projects, you can create instead a shared DLL holds you class by adding additional project to your solution, write the class you need and reference it to both project.
This will make your DLL to be apart of the two applications without writing your code twice.
I have a question regarding development architecture and what would be considered to be the ideal organization of code and logic.
I am working in a company that has multiple C# solutions, with multiple projects accessing multiple databases. Some projects access only one database, some others access all of them, and so on.
Right now, the management of each database is made inside each project. I have been thinking about creating libraries to unify all this process.
Could somebody give me some insights regarding this? What would be the best way to work on this?
I've been thinking about centralizing all the Database logic inside a solution, with separate projects for each Database. This way I can create Class Libraries that will compile DLLs for each of them, that can be referenced between projects and solutions.
What do you think about the concept above, specially working using Entity Framework?
Thanks in advance.
We have a very similar situation.
For each database, we have a separate class library project. The project contains the context, entities and associated migrations.
Each product references the class library or class libraries that correspond to the database(s) it works with.
When we first started, each developer would check out the class libraries, build locally and reference the locally compiled DLL (which we copied to a known location with a post build event). It turns out that it's remarkably easy to setup your own NuGet server and publish updates to that server. We transitioned to that solution a few months back, and it works wonderfully. There are also a number of hosted NuGet providers.
This should be the way to go yes. I would create a solution for that purpose, abstract all database connectivity logic there and then use it from other solutions just handling different ConnectionString's.
I recommend to take a look at NuGet if you already haven't, you will have many advantages with this package manager for sure!
I think one centralized database which has all the common entities among your applications can be useful here. if you want to keep the other databases is fine too, you can use replication to transfer data from master database to other databases and consume them in their applications
I recently attended a demo of a large-scale enterprise system, whose web pages may be customised to the point of including fields added by the client. The way I understand it, their architecture is made up of the following layers:
Database
Web service API
XML files that dictate layout
The web pages that are generated from the XML files.
When I was asked to investigate building a web portal which could be easily branded, that struck me as a good way of going about it. The question now, is how one would design it.
I understand the database and web service layers, but I am a little confused by the various possibilities for building web sites in .NET.
Considering the requirement for customisability and the architecture from above, here is how I understand the options:
Webforms - the option I am most familiar with, but it is essentially enriched HTML with code-behind. I think there will probably be a lot of work to make it work with the idea of an XML layout.
WPF - the XAML middle layer is built-in, but as I understand it, WPF can only really be used in browser applications and not websites.
Silverlight - more for building applets than websites, right?
MVC - This looks interesting, but all the demos I have seen use Entity Framework as well. It seems to me like Entity Framework with all its automatic code generation is much more suitable to applications that are all new. In my case, I have a very large database that already exists.
If none of the above are suitable, I thought of an alternative. One could do a stock standard Webforms site with a web service that returns the branding elements. That isn't quite the same as what I described at the top, but is sufficient for my needs.
Or am I barking up the wrong tree?
I think you're off on your criticism of MVC. First, you don't need to use Entity Framework, and secondly even if you did, you can do it database first to generate your entities.
Your assessments of WPF and Silverlight is pretty spot on imo.
You could do this with webforms, but I think you'll probably find doing it with MVC architecture will be cleaner. Very simply, if you use clean HTML and put all branding elements into an external CSS file (logos, colors etc), then you are half way there to a custom brand. Even a different layout could potentially be defined by the CSS file (although it might be harder for your end users to customize that look since they would need to know css pretty well)
Building additional fields is potentially more difficult:
Off the cuff, the way I'd be looking at implementing this would be a combination of my predefined fields in a standard database layout (users table with username, password, first name, etc etc) and additional support for the "customizable fields" using the Entity-attribute-value pattern
From there you will need to develop an extensible system to 1. generate a page from xml with the appropriate form elements (select, text input, textarea, etc). 2. Generate a generic model that will read the same XML file and be able to receive data from a posted form and know how to save that to the database (note in this case if it was ALL entity-attribute-value that would probably be easier to manage than a combination of standard relational and EAV).
You'll probably want to look at .NET Data Contracts as serializable entities to get an understanding of how you might design your XML files to be extensible to allow for things like "select menu has the following 3 options" or text input must match this regex.
Really keep an eye towards extensibility, because you can't build it all at once.
Can you please provide me with some tips/guidelines when architecting, designing and implementing a .net framework application, with the requirements given below:
It will be an analytical tool which will retrieve data from files, sql databases and may be cubes. So data layer should be able to handle that. The middleware should be totally independent of the other layers so probably need an IoC container (which one would you recommend)
It will be deployed on the local intranet
The front layer might be WPF application or Silverlight in future (for now, I am concentrating on Silverlight but the point is that it will change)
It should be easy to customise and improve it in the future without changing much of the code as the framework will be deployed for many clients
I need a way to store the configuration information, which will be picked up by the application on application load events to set its feel and look.
I have two months to implement it and looking for as many tips as possible.
SoC for a start
break your application into several assemblies that use IoC (interfaces + implementations):
application model assembly - all other assemblies will reference this one because these classes will be used for inter-communication - they will mostly be just POCOs
presentation assembly - references app model and business services - this one is either WPF or Silverlight in any case use MVVM to make your testing life easier
business services assembly - references app model and data repositories assembly
data repositories - these define repositories that actually get data from the stores
Then I'd create three additional ones:
file data providers
database providers
cube providers
Data repositories would reference all three and use them to provide necessary data.
If configuration becomes very complex with a lot of functionality then you should put it in a separate assembly as well and reference it by business services assembly.
Which MVVM library to use
Since you mentioned time I suppose you'll have hard time catching your deadline. When using MVVM (which I suggested to use) I also suggest you don't use a full blown PRISM (a.k.a. Composite Application Guidance from P&P) but rather go with MVVM Light Toolkit. It will take you less time to get on the bandwagon.
Code generation
In places where appropriate I suggest you use T4 to its full potential. I use it to import stored procedure calls to avoid using magic strings when calling stored procedures (and using their parameters). Check my blog post about it as well.
DAL technology/library
Don't write your own data access code using things like SqlConnection/SqlConnection functionality. There're many data access layer libraries/technologies today that you can use and not reinvent the wheel. If you know nHibernate, then use that. If you know EF, then use that. If you know anything else, use that. Anything that will provide/generate as much code for you as possible that is already tested and debugged.
So it all boils down to:
DRY + YAGNI
a.k.a. Don't repeat yourself and You ain't gonna need it = don't over-engineer you code.
Agile developers are supposed to be lazy
They should develop just as much as it's needed and no more! TDD implicitly provides this process by the red => green => refactor steps.
I would recommend using MVVM and Test Driven Development. The MVVM will give you good separation between the front and middleware, and the TDD will help control the chaos that comes with any nontrivial app development.
Have a look at the Composite Application Guidance from Microsoft's Patterns and Practices group, it may not match what you are doing exactly but will give you some good ideas.
From an architectural standpoint, I highly recommend taking a look at the Microsoft Application Architecture Guide. Since you are already using the Microsoft technology stack, I would consider using Microsoft Unity for IoC. You indicated that your presentation layer might use WPF or Silverlight, so take a look at using Windows Communication Foundation, as you will be somewhat constrained in Silverlight when it comes to communication with your data layer.
I am designing this HR System (desktop-based) for a mid-size organization. The thing is I have all the tables designed and was planning on using the O/RM in VS2008 to generate the entity classes (this is the first time I work with OR/M; in fact, this is my first "big" project.) I wanted to make the app with 3 layers (one of the programmers of the company suggested not 3 but 4 or 5 layers) but after reading quite a lot of blog entries and a lot of questions here I've realized that is not quite easy to do that with LINQ to SQL because of how the datacontext works and how difficult it is to pass objects between layers using LINQ to SQL.
Probably I'll just use the entity classes generated by the VS2008 ORM and add any validation and bussines logic in partial classes. But that would be 2 layers, or not? The app will be used by like 10 users, so I don't think the 2 layer approach is a big issue for now.
In the future, a web-based front-end will be developed so candidates can apply to jobs online. I want to develop it as scalable as possible. But the truth is I don't have a lot of time to waste to make a decision, times running up hehe.
Having said all that, should I just use the entities generated by the VS2008 ORM?
So any suggestion or idea would be greatly appreciated. Thanks.
You're chewing over quite a lot with your line of questioning here. (Is there a concrete question hidden in there somewhere?)
With layers, I assume you mean physical boundaries, i.e. application, app/SOA/WCF server, data layer that lives on the SOA server, and a database somewhere.
Designing for the future might seem like a good idea, but DO make sure that there WILL be a need for all those layers somewhere down the line. Essentially, you do not need a WCF/SOA based approach if you're not exposing your application over the internet at some point. A web frontend can solve the same problem in many cases.
I'm not saying you will not need those layers at all, but you might not. If you really do, seams are your friend. You need to make "cut points" where you can define your boundaries. I commonly use the repository pattern to diversify data access methodologies, and use plain objects (POCO) and interfaces that are persisted via technologies such as NHibernate. Using POCOs also makes it MUCH easier to transfer those objects over the wire at a later point, either standalone or part of messages.
Creating service interfaces that are called can solidify your boundaries. When you are ready to move cross-machine/physical boundaries, you simply create your boundaries in the service implementations.
It sure sounds like a dangerous way to go - creating the tables first, then domain and finally GUI.
I must admit I am no expert on ORM expert but the generated classes I´ve seen looks more like dataobjects than classes. I would say you need another layer to stop all logic to end up in the GUI ).